packagekit as backend for software-center
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://
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
- Started by
- Completed by
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-
- 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.
