GNOME-PackageKit packaging

[Matthias Klumpp]

On Sat, 04 Dec 2010 15:23:51 +0100, Julian Andres Klode <jak at debian.org>
wrote:
> 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.
... which is just a copy of the PK concept.

> 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...
...do you say PackageKit, which was designed for exactly this case?

> 
> 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
Okay, why not base all this on existing PackageKit code? Could look like
the following:
 Operation: Codenamed: PackageKit + Debian;
 ==========================================
 
 Backend:        Cupt/APT/APT2
                     |
 Service:          packagetoold
                     |
 Common Client:    libpackagekit-glib2 or libpackagekit-qt (PackageKit
bindings)
                     |
                   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
 ... or use the PackageKit UIs:
         libkpackagekit (KDE) libpackagekit-gtk (GTK+)
         -> KPackageKit         -> gpk-application
         -> ...                 -> gpk-repos
                                -> ...
 
 The goal:
       * A C/Vala library managing packages:
               * The cache is accessed directly
               * Installation/removal happens via D-Bus
       * Only one D-Bus service:
               * PackageKit for all stuff which needs to be executed as
root
       * 4 applications using the library:
              A. Package Manage   => low-level PM like Synaptic, using a
Debian-specific package-manager lib
              B. Update Manager   => combination of -manager, -notifier,
can be based on PackageKit
              C. Software Center  => application-oriented version of A,
can use PK
              D. Software Sources => manages sources.list, can also use PK

(*) => Libpackagetool could use the PackageKit-daemon if possible,
otherwise, for example for searching the cache, it could use APT directly.

Would provide exactly the same stuff be reusing existing and well-tested
code. Why not improve PackageKit?

> 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.
Yep, exactly. PackageKit serves all needs of Debian at time, and AFAIK as
a long-term-plan, USC will base on PK too. I can also imagine to use PK for
all privileged actions Synaptic performs. Since PK supports Debconf,
there's no APT feature, except some special ones like APT-pinning, which is
not supported by PK.
I will ask Richard and Michael if we could set up a discussion on IRC or
something similar about this.
Kind regards
    Matthias