GNOME-PackageKit packaging

[Julian Andres Klode]

On So, 2010-12-05 at 17:40 +0100, Matthias Klumpp wrote:
> 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.
Not really. QApt's concept differs by using the APT cache directly.

> 
> > 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:
I did not say that it's not PackageKit, PackageTool is just a name which
in the end is substituted by the final solution which can be PackageKit,
or something else.

> > 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.
APT pinning is a feature for advanced users only and should not be
exposed in the frontends. You cannot do useful things with it in the
frontend anyway. But there are other problems:

      * 'Software Sources' does not allow editing of sources
      * Bug#606025: packagekit: Does not support conffile
      * How will multi-arch and tdebs work once they are there?
      * PackageKit hatred in general


> I will ask Richard and Michael if we could set up a discussion on IRC or
> something similar about this.
> Kind regards
>     Matthias


-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

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