GNOME-PackageKit packaging

[Julian Andres Klode]

On So, 2010-11-21 at 18:45 +0100, Josselin Mouette wrote:
> It’s not a problem of conflict or whatever. Again, I’d like to see a
> *consistent* software stack for package management. Having pieces of the
> stack based on the PK backend and others based on aptdaemon is not a
> long-term solution. Either we can base everything on aptdaemon, or we
> can base everything on PK - oh wait, the crippled PK interface doesn’t
> make this possible.

Recently, I was looking a bit more at the Qt/KDE world, and found QApt
and Muon. This is what we should be looking at for inspiration, and the
base of the ideas outlined hereinafter.

We have to get rid of all applications currently running as root, we
have to get rid of services like aptdaemon written in Python, and we
need to create a common service useful for all desktop environments, and
shall have clients for KDE and GTK+ environments. Finally, we also need
to deal with developments such as multi-arch which are currently not
handled at all. So here comes...

Operation: Codenamed: PackageTool; draft 1
==========================================

Backend:        Cupt/APT/APT2
                    |
Service:          packagetoold
                    |
Common Client:   libpackagetool
                /              \
               /                \
UI:     libqpackagetool (KDE) libgpackagetool (GTK+)
(A)     -> kpt-packages        -> gpt-packages
(B)     -> kpt-updates         -> gpt-updates
(C)     -> kpt-software        -> gpt-software
(D)     -> kpt-sources         -> gpt-sources

The goal:
      * A C/Vala library managing packages:
              * The cache is accessed directly
              * Installation/removal happens via D-Bus
      * Two D-Bus services:
              * An Implementation of PackageKit
              * A custom one, inspired by aptdaemon and QApt
      * 4 applications using the library:
             A. Package Manager	 => low-level PM like Synaptic
             B. Update Manager   => combination of -manager, -notifier
             C. Software Center  => application-oriented version of A
             D. Software Sources => manages sources.list

Each application shall only do one thing. A and C shall install/remove
packages, but not manage updates. B shall update the system and display
notifications.

This is just a rough draft (and somewhat of an APT2 plan at the same
time), I do not have much precise stuff yet. It's basically like
PackageKit, just from the Debian perspective.

On the library side, libpackagetool should not expose any D-Bus
specifica, and keep the D-Bus specific parts in a module; allowing it to
be used to implement backend as well (that's APT2's plan).
lib{g,q}packagetool provide common widgets for the applications.

We shall explore what we can do with PackageKit in this area, whether it
is possible to enhance it to do what we need to do (by adding methods
prefixed with Debian if needed); or whether we should go our own way.

Alternatives
============
I do not know what Canonical's and {K,}Ubuntu's future plans are with
regards to package management. I CCed mvo in the hope that he can
outline their plans.
-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.