PackageKit: new backends and discussed at Ubuntu conference

PackageKit gains more and more attention these days: with Pisi and Smart two new backends have been added and PackageKit was discussed at an Ubuntu conference as a possible default package manager.

Richard Hugehes’ PackageKit – a tool for unified package and software management on Linux regardless of the distribution’s backend – was first introduced around July/August this year. Since that it gained an unbelievable development speed and was improved on an almost daily rhythm.

New Backends

Two weeks ago PackageKit released 0.1 version and marked the API as stable. More and more distributions now realize that PackageKit can indeed become what everyone hoped for and start implementing support for the various backends. The last two added backends add support for Smart and Pardus’ PiSi.
The backend matrix currently looks like this:

PackageKit features and backends matrix
conary yum apt box alpm Smart PiSi
resolve X X X X
refresh-cache X X X X X X
get-updates X X X X X
update-system X X X X X
search-name X X X X X X X
search-details X X X
search-file X X
install-package X X X X X X
install-file X X X
remove-package X X X X X X
update-package X X X X X X
get-depends X X X
get-requires X X X
get-description X X X X X X
get-repo-list X X X X X
repo-enable X X X
repo-set-data X
cancel-transaction X

Keep in mind that PackageKit was first development for yum and apt. Nowadays other backends are even better supported than yum. In a far future this might even lead to a situation where the backend is developed with the needs and possiblities of PackageKit in the mind. I doubt that any backend developer would like to have the least supported backend if PackageKit gets really wide spread.

PackageKit at Ubuntu conference

PackageKit was also discussed at a recent Ubuntu conference:

The result of this general enthusiasm is that Canonical will likely move forward with the adoption of PackageKit in the near future, although they will need some time to make some adjustments to their own packages first. For example, PackageKit does not permit interactive questions (like agreeing to licenses) during the installation process; dpkg does. As a result, the few remaining .deb’s that still require interactive feedback during install will have to be adjusted to be non-interactive.

The same report also mentions that PackageKit is now widely accepted by rPath distributions. Congrats, PackageKit.

But this discussion also shows the problem between powerful backends and the real world: while it is an interesting feature to have a package/software manager with an interactive mode it is just a feature which is usable by real power users. Normal users cannot answer interactive questions of any kind (maybe licence questions, but that’s it) and therefore distributions which have regular users in their mind should not offer that possibility.
For the same reason PackageKit should not include support for it – it would spoil the entire idea of making the package management easy.

At the moment it looks like PackageKit is the new shining star in the Linux world when it comes to package management. At the moments there are only three things missing to have world domination for it: a zypper backend for OpenSuse, an urpmi backend for Mandriva and a KDE GUI.