[packagekit] PackageKit DBus Interface in Ubuntu - It is the API that matters!
glatzor at ubuntu.com
Thu Nov 17 07:50:17 PST 2011
On Thu, 17 Nov 2011 13:18:16 +0000, Richard Hughes <hughsient at gmail.com>
> On 17 November 2011 11:41, Sebastian Heinlein <glatzor at ubuntu.com>
>> AptDaemon will just be another implementation of the PackageKit API -
>> with packagekitd as the reference implementation. We won't support
>> last piece of PackageKit but those which are relevant for an APT based
>> package managing.
> So, can you clarify which bits of the API you are supporting, and also
> the extra API you're intending to add. If the complete API isn't
> implemented, I think it's an exaggeration at best to call it "another
There won't be any additional API compared to the PackageKit one. It is
all about compliance. The AptDaemon D-Bus interface is still available and
will be used by e.g. software-center or update-manager. All methods and
properties of the org.freedesktop.PackageKit and
org.freedesktop.PackageKit.transaction interface are available and behave
in a sane way. The supported and not supported roles and filters are
clearly communicated to the client - thanks to the PackageKit
infrastructure which has to support backends with different capabilities
and degrees of integration. One exception is for example the CanAuthorize
method which always returns "interactive" currently or the ignored
store-in-cache property of DownloadPackages (the packages are always stored
in the APT cache).
The focus is on the DBus interface only. AptDaemon won't support sharing
the sqlite transaction log or configuration files with PackageKit.
Furthermore the PolicyKit priviliges of AptDaemon are used. There are also
no plans for alternative backends.
> I also think it's a shame the new API couldn't be added to PackageKit
> itself. Even stuff like AddLicenseKey would make sense as it could be
> re-used by RHEL, SLED and that kind of thing.
The most important thing for me was to get the PackageKit API into Ubuntu
and no longer block any client applications and so the adoption of the API.
Aptdaemon won't go away in the next one or two years.
It was also a shame that we could not aggree on the policy some years ago
and now have got a PackageKit allowing debconf and config file handling -
those have been the main reasons for the development of AptDaemon if I
More information about the PackageKit