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: packagekit-intrepid
Packages affected: gnome-app-install, packagekit, packagekit-gnome
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). See package-kit for overall plans related to packagekit.
This spec describes the steps we will take to make use of packagekit in Intrepid.
Applications can now make use of PackageKit in order to install any extra packages they need at runtime.
One of the most important aspects of PackageKit is libpackagekit that allows applications to install extra packages they need at runtime (the next gnome will make use of that feature). This means that an application can install plugins/themes/etc. when the user uses that feature, meaning that they don't have to depend on so much, and can provide a better UI for some operations. In order to allow applications to make use of this we need the core of packagekit available in the default install.
There are some known issues with PackageKit and apt related to interactive installs and the like. The aim for Intrepid is to try and make use of these PackageKit without having to solve these issues up front.
- A user wants to use Inkscape to open a file in a rare format. Inkscape supports this, but needs a certain package installed to be able to do it. Instead of having to depend on libraries for every obscure format, or refusing to work and optionally displaying instructions of what package to install, Inkscape can offer to install the package directly, and then carry on.
- The user goes to the font dialog to select CJK fonts and gnome-apperance-properties offers to install them.
Firstly, we will include a recent version of packagekit in to the distribution. libpackagekit will then be available for packages to link against.
We will include the packagekit daemon/backend in to the default install, meaning that it will be available for any packages that want to make use of it.
To start moving things over to packagekit we will port gnome-app-install and software-properties-gtk to use packagekit where possible. This has the added benefit of making them policykit compatible.
The packages of packagekit are currently following the 0.1 branch. This needs to be updated to use the 0.2 branch, which will involve a bit of effort in backend development. We will try to move the backend to "apt2" that is dbus based and much faster than the current "apt" backend that works by spawning processes. They also should be split to provide a proper libpackagekit package if other applications are going to start linking against it. Main Inclusion Reports will also be filed.
The packages that can be installed by gnome-app-install will be audited to check for packagekit compatibility. Any issues that arise from this will have to be discussed with upstream. We will certainly need to modify the apt backend to support the EULA signal for things like flash or java. We may need to discuss with upstream extending this to work in a way that means we can make debconf use it.
Then gnome-app-install and software-properties-gtk can be ported to packagekit, discussing extensions to packagekit where needed with upstream.
- Check what happens when libpackagekit is used but the daemon is not installed.
- Evaluation of gnome-packagekit for inclusion in the default install.
- Assesment of impact on derivatives (Kubuntu especially), and discussion about plans with them.
- Discussion with upstream to make sure that providing a real libpackagekit will be feasible (SONAME issues).
- We need a good way to audit packages for user interaction outside of debconf.
- Add code to the apt backend that can kill hanging postinst script (that wait for input).
- How much is lacking from packagekit to port gnome-app-install and software-properties-gtk.
Please add any comments here: