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 -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
