PackageKit DBus Interface in Ubuntu - It is the API that matters!

[Sebastian Heinlein]

Servus dear developers,

In the current development cycle of Ubuntu I am working on bringing the
PackageKit system D-Bus interface to the Ubuntu desktop. This will be
done by adding a compatibility layer on top of AptDaemon, the software
management service in Ubuntu. 

AptDaemon will just be another implementation of the PackageKit API -
with packagekitd as the reference implementation. We won't support every
last piece of PackageKit but those which are relevant for an APT based
package managing. 

The reasons for this: PackageKit is separated into two D-Bus interfaces.
On the one hand the system DBus interface which provides a full fledged
API for a package managing application (e.g. an update manager or an
application installer) on the other hand the session DBus interface
which should be used by third party applications only. Since we already
had powerful package mangers (software-center and update-manager) there
wasn't any need to focus on the system DBus interface. The session DBus
interface was implemented by session-installer for Ubuntu/Debian.

But nowadays with GObject Introspection and a better client library the
use of the session interface isn't very popular anymore. Some GNOME
applications directly use the glib based client library, e.g. nautilus
gnome-settings-daemon or the coming region/language settings. 

A second reason is that some Ubuntu specific applications want to query
for updates (session-indicator). It would make sense to provide a DBus
based API here. So the use of PackageKit's GetUpdates method is the
obvious choice. This would also allow to use the gnome-settings-daemon
update and firmware plugins in favor of update-notifier in the long run.

A valid question is: Why not replace AptDaemon by PackageKit at all? The
answer is that we need a highly integrated backend for software-center:
chaining of transactions, storing meta-data in transactions, handling of
purchases, downloading while installing (coming feature), inheritance of
PolicyKit priviliges, configuration file conflict support, fast adding
of new API (e.g. AddLicenseKey) ... 

The unit tests are done by using the Python GObject introspection client
of PackageKitGlib to ensure that the layer works fine for every
PackageKit based application.

If PackageKit is installed on the system it will be preferred over
AptDaemon.

By mapping AptDaemon transactions and reusing the code from the former
apt backend of PackageKit for the query methods most of the PackageKit
roles have been implemented:
  
* refresh cache
* simulate (update|install|remove) packages
* (download|update|install|remove) packages
* get distro upgrades
* upgrade system
* get packages
* get files
* get (update) details
* get (depends|requires)
* search (name|details|file|group)
* resolve

This leads to a fully working gpk-application or gpk-update-viewer with
AptDaemon - but to be honest not at the same speed compared to
PackageKit.

Moving to the hopefully soon landing server GDbus python bindings and
internal threading in AptDaemon we will see some performance gains in
the future.

The development currently takes plance in the
lp:~aptdaemon-developers/aptdaemon/pkcompat2 branch and will be merged
this week into the main branch.

Cheers,

Sebastian

https://wiki.ubuntu.com/AptDaemon/PackageKitCompat