packagekit as backend for software-center

Registered by Robbie Williamson on 2009-11-06

evaluate using packagekit as backend instead of aptdaemon. There is some work in PK to support debconf and there is a push for inclusion in gnome 2.30.

This should include check if we can use the app-install http://github.com/hughsie/app-install system and port SC to use
the metadata and PK as its backend. This maybe a multi step effort.

Blueprint information

Status:
Not started
Approver:
Robbie Williamson
Priority:
Undefined
Drafter:
Michael Vogt
Direction:
Needs approval
Assignee:
Canonical Foundations Team
Definition:
Discussion
Series goal:
None
Implementation:
Not started
Milestone target:
None

Related branches

Whiteboard

PackageKit wants to provide a common D-Bus interface for package management on all distros. It is transaction based and makes use of PolicyKit-1.
Some Gnome and KDE applications have started using the PackageKit session API to request installation of particular packages (e.g. codecs, fonts).

Aptdaemon was created as an instant replacement for PackageKit allowing pausing a package management transaction for user input, e.g. debconf, config file prompt and media changes.

Fixed showstoppers in PackageKit:
 - Require special privileges to install untrusted software packages (and not only show a warning message about untrusted packages which have been installed)
 - Preview of complex operations (installations which require downgrades etc.) by introducing Simulate* methods
- Debconf support now implemented

General open issues:
 - missing config file conflict handling (still set to keep the old, modified version). In the long run this will be handled by debconf integration into dpkg, see above.

Software-Center-specific showstoppers:
 - Only sequential transactions: Querying and modifying is queued in the same queue, so long taking updates can block a simple query for quite a long time
  * Richard Hughes says this is far from being fixed

Advantages of packagekit in software center:
 - only one package management abstraction level to maintain
 - could be used as a replacement for aptdaemon for package install/removal
 - (Sometimes) faster and uses less memory than aptdaemon

Advantages of packagekit:
 - provides session API to install packages by other apps like nautilus
 - Cross-Distro standard which is used by many other distributions. Using it would increase compatibility to them.

Advantages of aptdaemon:
 - Slick approach only focusing on doing the work which requires root privileges with a small code base
 - Working support for configuration file conflicts
 - We don't need to fork PackageKit (or wait for upstream consensus) before fixing UX problems that require an API change
 - awesome maintainer

Open issues in aptdaemon:
 - API cleanup on the server and client side, reducing the number of signals

== For Lucid ==
 * Don't put packagekit into software center, but support packagekit session API elsewhere on desktop (using so-called sessioninstaller project)

Another feature making its way into Packagekit which i think is a good reason for its inclusion is the ability to install updates at boot. This is specially a nice feature for server/corporate installs.

(?)

Work Items