ubuntu-appstore-developers team mailing list archive

[Sebastian Heinlein <glatzor@xxxxxxxxxx>]

Hello,

At the virtual UDS session about click packages there was a short side
discussion about the API for the communication between the GUI
components and the higher privileged click package system. I would like
to raise this issue again.

There are currently several existing IPC methods for managing software
in Ubuntu (AptDaemon system D-Bus, PackageKit system and session D-Bus
or command line interfaces e.g. apt-add-repository or the dash/s-c glue
code). It would be nice to avoid a wider fragmentation with the
introduction of click packages.

AFAIK the required API of the AppStore would be quite small and the
package downloading and update calculation is done in the GUI component,
right? So we could end up with a very small set of methods e.g.
InstallFile() RemovePackages(), GetPackages(FILTER_INSTALLED)?

There are two well tested daemons that could be re-used, support a
transaction based model and already handle many of the the small details
correctly:

Aptdaemon is used by Software Center, Update-Manager and
SessionInstaller for managing software in Ubuntu. Since APT is only
accessed in the aptdaemon.worker.Worker class - the class could be
replaced by a worker that makes use of click packages. The disadvantage
of this solution is a missing non-Python based client library.
Furthermore it limits the click package implementation to Python or
requires a Python library to access the click packages system.

On the other hand there is the PackageKit daemon and its D-Bus API. The
PackageKit daemon allows to write backends in different languages: the
current Python based click package system could use a spawned backend.
If it is still the plan, click packages could be re-written in C/C++
later without having to do any changes on the communication between the
daemon and the client. Furthermore PackageKit features a nice
GLib/GObject introspection client library - and even a QT based one.

Since aptdaemon provides a PackageKit D-Bus interface implementation
next to the native aptdaemon interface you could theoretically use the
packagekit daemon on the phone and keep aptdaemon on the desktop. I
don't know what the future of software-center will be at all and how it
fits into the scenario.

The support for the latest PackageKit 0.8 system D-Bus interface landed
in aptdaemon's trunk today. I plan to release and upload a 1.1 version
of aptdaemon soon. This will unblock the transition to packagekit 0.8.9
for saucy.

I could assist in modifying aptdaemon's worker or in writing a Python
PackageKit backend for click packages. The old and somehow obsoleted
Python based apt backend (in contrast to the aptcc backend) also
demonstrates how to write a test suite for Python backends.

Cheers,

Sebastian

P.S. Here is a small summary of the PackageKit/aptdaemon situation
because it sometimes causes some confusion:

PackageKit provides two D-Bus interfaces to manage software. The system
D-Bus interface should be used by the native client libraries. For
applications that cannot access the client libraries or don't want to
provide a separate graphical user interface that handles errors or shows
the progress there is also a small session D-Bus interface which is
implemented by gnome-packagekit and apper.

The PackagetKit daemon supports several backends. The backends can be
written as a native C/C++ backend featuring even parallel transactions
or as a spawned backend that communicates by a pipe with the packagekit
daemon. Theoretically the spawned backend be written in several
languages, but Python is the only supported one.

There are two PackageKit backends that are relevant for Debian/Ubuntu.
The APTcc backend by Danilo and my old Python APT backend that only has
got historically value nowadays - to be honest.

Aptdaemon was written since several years ago PackageKit did not allow
to have any interactiveness during a running transaction by design
policy: So no terminal support, no debconf or config file conflict
support. The policy was relaxed and debconf and config file conflict
prompts are nowadays supported.

Aptdaemon has got a similar but different D-Bus interface that is more
APT and Ubuntu/Soiftware-Center specific. But as an addition the daemon
also provides the PackageKit system interface.

Sessioninstaller (to introduce one more piece of software :) provides
the PackageKit session interface, but uses aptdaemon or synaptic as a
backend.