PackageKit

Differences between revisions 5 and 6
Revision 5 as of 2008-01-02 15:30:58
Size: 3028
Editor: jan4
Comment: debian wiki link added
Revision 6 as of 2008-05-07 09:38:59
Size: 5726
Editor: 91-65-148-12-dynip
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
 * '''Packages affected''': apt, synaptic, update-manager, gnome-app-install, adept, gdebi  * '''Packages affected''': apt, synaptic, update-manager, gnome-app-install, adept, gdebi,
Line 21: Line 21:
PackageKit is a very interesting project that promises a unified way of package manipulation tools across all distros. 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. 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, conray, 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.
Line 25: Line 32:
 * Bob comes from a different linux distro that uses PackageKit and switches to Ubuntu. He feels at home immediately when he finds that ubuntu offers PackageKit too.  * Angeliquie wants to install an application. It works without any disturbing focus stealing or popup dialogs.

 * Fred preforms a system updating. But the GNOME session crashes. Nevertheless the update continues in the background and gets applied successfully.
Line 29: Line 39:
The next ubuntu release will be a LTS so we take a cautious approach
to the adoption of PackageKit. We will package Packagekit and make it
available in our repository. Applications like gnome-app-install and
update-manager will be prepared for switching by abstracting the
backend (currently python-apt) so that it's easy to flip a switch and
make them use packagekit.
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.
Line 36: Line 41:
We need to investigate and discuss with upstream what to do about
interaction during a package install. Currently during a package
install, interaction may be required for:
 * conffile prompts
 * debconf questions
 * terminal interaction

The debconf prompts can be made non-interactive easily with
DEBIAN_FRONTEND=noninteractive. 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).
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. This problem needs to be
discussed with upstream. A possible solution is to provide an
extension to the current protocol that is debian/dpkg
specific. Another is to make terminal interaction deprecated in debian
policy and get packages to follow that.

We need to review the current status of the apt/dpkg backend and
help improve it.
Line 62: Line 44:
Some packaging work is done by Sebastian Heinlein in
https://code.edge.launchpad.net/packagekit/. A packagekit team is
The packaging work was done by Sebastian Heinlein in https://code.edge.launchpad.net/packagekit/. A packagekit team is
Line 68: Line 49:
Interaction during install is a problem for us that needs to be solved
first.
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 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.
Line 72: Line 71:
There is a Debian Wiki page: http://wiki.debian.org/PackageKit -- AzraelNightwalker [[DateTime(2008-01-02T15:30:58Z)]]

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. 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, conray, 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 updating. 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.edge.launchpad.net/packagekit/. A packagekit team is 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 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 124-170-206-72)