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. -- Mailing list: https://launchpad.net/~ubuntu-appstore-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-appstore-developers More help : https://help.launchpad.net/ListHelp
