PackageKit

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

  • Launchpad Entry: package-kit

  • Packages affected: apt, synaptic, update-manager, gnome-app-install, adept, gdebi,

Summary

PackageKit is a new cross-distro framework that abstracts from the actual underlying package system. Backends are available for systems like yum, apt, conary (and more).

This spec investigates how it affects us and if/how we can make use of it.

Release Note

TBD

Rationale

PackageKit provides a cross-distro mechanism to perform package (installing, removing, updating, etc) and repository (enabling, disabling) manipulation. The project leader and main developer is RedHat's Richard "hughsie" Hughes. With PackageKit upstream projects can integrate software installation functions easily without caring about the package management system of the distro in which it gets shipped, e.g. FireFox could install extensions or OpenOffice could install extra fonts or documentation. But currently PackageKit is only used by itself.

Since there are already backends for many package management systems (yum, zypp, apt, conary, smart, alpm, box, opkg) and the system gets pushed by RedHat/Fedora. Ubuntu should not miss this new technique. The apt backend is written in Python is developed by Sebastian Heinlein and already allows to perform basic tasks (see http://www.packagekit.org/pk-faq.html).

Furthermore PackageKit introduces a separation between the graphical user interface and the actual package manipulation, since it provides a DBus controlled system daemon which only runs if required (DBus activation). So the tasks don't get interrupted by a desktop crash and there is a consistent multiple user behavior. Additionally PolicyKit is used for the privilege handling. The graphical applications don't need to run as root anymore and privileges can be granted in a more fine grainted way.

PackageKit ships with a small set of graphical applications: install/removal tool, system updater, update notification icon. They are used by Fedora 9 as the main package manipulation tools. PackageKit does not want to replace the advanced package management tools e.g. Synaptic and focuses on basic and non interactive package manipulation tasks. Since Ubuntu requires more advanced features in update-manager or gnome-app-install this applications can not be replaced (yet). But it could be used to replace the Synaptic calls in g-a-i, u-m, language-selector, since those apps don't perform the package manipulation tasks on their own.

Use Cases

  • Angeliquie wants to install an application. It works without any disturbing focus stealing or popup dialogs.
  • Fred preforms a system update. But the GNOME session crashes. Nevertheless the update continues in the background and gets applied successfully.

Design

The next Ubuntu release will open a new developing cycle so we take a more brave approach to the adoption of PackageKit. PackageKit currently provides a stable branch 0.1.x and a developing branch (upcoming 0.2.x series). We will need to update the apt2 backend for the new branch and add missing functions. Currently only the 0.1.x is packaged.

Implementation

The packaging work was done by Sebastian Heinlein in https://code.launchpad.net/packagekit/. A packagekit team has been created.

Outstanding Issues

Since PackageKit only allows non-interactive package management tasks there are currently some open issues. A more detailed discussion about these issues can be found here: http://wiki.debian.org/PackageKit

Config file prompts

For the configuration we could add --force-confnew or --force-confold to the dpkg commandline (also this would conflict with the expectations that traditional users have). A decision has to be made which option to use and perhaps taken to the Technical Board.

Debconf questions

The debconf prompts are made non-interactive with DEBIAN_FRONTEND=noninteractive.

But this affects licence agreements too e.g. for Sun's java and Adobe's Flash, since those are shown as a debconf question. PackageKit provides an EULA agreement method. So we would need to add special handling for these packages in the apt backend.

Terminal interaction

The terminal interaction is the hardest problem. It is currently not forbidden by Debian policy to ask terminal questions and some core applications like libc6 do that in situations. This is a problem for an application like update-manager where there is no control over the packages that are going to be installed. The best option would be to make terminal interaction deprecated in Debian policy and get packages to follow that. Otherwise we would have to create a blacklist for all affected packages. To get a better idea of the problem and how widely it is spread we should think about how we could detect corresponding packages.

Apt Xapian

The apt backend of PackageKit can make use of apt-xapian-index which provides a marvelous fast way of searching in the package cache. It allows to perform as-you-type searches - a long outstanding feature requested by usability engineers in Synaptic. The problem is currently the cache creation which takes a minute or two on a modern hardware. The developers of the apt backend is in contact with Enrico Zini, the creator of apt-xapian-index. Enrico is open for suggestions and improvements.

Comments


CategorySpec

DesktopTeam/Specs/PackageKit (last edited 2008-12-28 10:31:49 by jeremy-visser)