Ubuntu Wiki

• Launchpad Entry: aptdaemon-p-pkcompat

• Created: SebastianHeinlein

• Contributors:

• Packages affected: aptdaemon, packagekit

Summary

Release Note

PackageKit based applications run on Ubuntu natively.

Rationale

AptDaemon was initially written to overcome the short commings of PackageKit for APT and to provide a deeper integration into the system. PackageKit is separated into two D-Bus interface. On the one hand the system DBus interface provides a full fledged API for a package managing application (e.g. update manager or application manager) on the other one 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 or the coming region/language settings.

A second reason is that also some Ubuntu specific applications want query for updates (session-indicator). It would make sense to provide a sane API here which uses caches. So the use of PackageKit's GetUpdates method would be good idea. 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)...

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.

User stories

Assumptions

Design

If the python-packagekit module is installed AptDaemon will automatically try to expose the PackageKit DBus object - if PackageKit daemon is already running the compat layer will be skipped.

AptDaemon will support the org.freedesktop.PackageKit and org.freedesktop.PackageKit.Transaction interfaces. Some transactions can be mapped to the currently available ones. For the query transaction a new transaction role will be used.

http://www.packagekit.org/gtk-doc/PackageKit.html http://www.packagekit.org/gtk-doc/Transaction.html

Implementation

1. MIR for python-packagekit, packagekit-common (?) 2. Merge pkcompat branch into AptDaemon trunk 3. Get threading ready in aptdaemon 4. Work on the missing bits in the worker

UI Changes

There aren't any UI changes.

Code Changes

There are two types of PackageKit transactions: ones which query the package cache and ones which manipulate it. The former ones can be easily mapped by using the currently existing AptDaemon transactions. This is already done for (Simulate)?(Install|Update|Remove)Packages and UpdateSystem. The query transactions need to be re-implemented. Luckily the code of the former apt backend for PackageKit and parts of session-installer and update-manager can be reused and so provide a solid base to build on.

The status, error, role enums can be easily mapped.

The unittests will use the PackageKit console command pkcon to verify the compliance.

Migration

There isn't any migration plan required.

Test/Demo Plan

Run gpk-application or gpk-update-viewer!

Unresolved issues

* PackageKit requires very fast response times on the DBus interface. So it would be great to move the APT cache handling to a separate thread, see aptdaemon-p-threading spec.

* How to handle DBus activation? Should we just ship the .service definition twice?

* How to handle the PackageKit dbus config file? Ship it in a new package packagekit-common?

* Provide a PackageKit object for every AptDaemon transaction with ROLE_UNKNOWN for AptDaemon specific transactions? Or just hide the AptDaemon transactions for PackageKit applications.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec