GNOME-PackageKit packaging

[Josselin Mouette]

Le dimanche 21 novembre 2010 à 18:06 +0100, Matthias Klumpp a écrit : 
> There are three choices at time: PackageKit + APTcc, PackageKit + APT and
> SessionInstaller + APTd.

Three choices for what?

Sorry but you are not considering package management as a whole. There
are the little thingies that can install packages from applications -
IMHO they are mostly useless, except the ones to install GStreamer
plugins. There are the upgrade management tools, and the package
installation tools, more or less advanced.

> Also, APTcc has a very active upstream and has less bugs.
> GNOME-PackageKit is a PackageKit *frontend*, so it might be possible to
> use GNOME-PackageKit with SI too. (But currently SI is not really
> feature-complete and also has some bugs. Last time I tried to use SI with
> KPK instead of the original PackageKit daemon, it didn't work)

GNOME-PackageKit is an interface for installing packages. On that matter
it does more poorly than e.g. software-center. And it’s only a part of
the picture.

What we need is a complete stack that is closely integrated, has no
feature overlap and uses, above all, a common, sane backend. Currently
we have no less than 3 backends (aptdaemon, packagekit and python-apt),
with overlapping functionality in software that uses it.

> > We really need to sit down and think about the future of package
> > management for the desktop. The situation in squeeze is not a
> > sustainable one, and misguided upstream choices (such as PackageKit) do
> > not help.
> Is SI used somewhere in Squeeze? I'm not familiar with the current
> situation in Squeeze, but it can't be that bad, otherwise that stuff won't
> be shipped.

It is that bad. In squeeze we have software-center, update-notifier,
update-manger and synaptic, with no less than 4 FUCKING ICONS in the
administration menu, all about installing or upgrading software. 4 icons
is 3 icons too many.

> Could you please tell me why you think the PackageKit concept is
> 'misguided'? The design of PK is - in my opinion - excellent, except for
> the missing Debconf support. So we sat down for this topic and the APTcc
> author created a Debian-compliant solution for Debconf in the APTcc
> backend, which Richard Hughes implemented in GPK and all tools which use
> lpackagekit-glib2 too. See
> http://blogs.gnome.org/hughsie/2010/11/02/packagekit-and-debian-2/ for more
> information.

The problem with PackageKit has never been Debconf. Richard Hugues has a
grudge against Debconf, because he disagrees with the concept of asking
questions at install time, so he always made it about Debconf. But
Debconf has a noninteractive frontend so you could always design a
crippled, but working, package manager without supporting it.

The problem is that PackageKit is designed, from top to bottom, for
Fedora. In Debian, where you already have a high-level interface, with
Python and D-Bus bindings, the *last* thing you want is another high
level interface that bases itself on calling other, existing high-level
interfaces, but stripping them down of their functionality. It is not,
by design, able to do anything more than install or remove a given
package. The API is very contorted just because it has, in the end, to
deal with rpm or yum command-line interfaces.

> So there is no policy conflict between PK and Debian anymore, or do I miss
> something?

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.

> Another thing: PK is not designed to replace Synaptic, aptitude
> or any other APT tool. It just provides simple tools for the PK user
> profiles (normal, non-technical users) and a distribution-neutral way for
> applications to access package management. So see it as an extension for
> package management, not as an replacement.

And that’s all the problem. It takes a very small problem, solves it in
a very specific way, without a thought for the situation as a whole.

We need to stop thinking “We want PackageKit” and start thinking “We
want working package management on the desktop”. On that topic, we have
a lot more to learn (and take) from Ubuntu than from Fedora.

-- 
 .''`.      Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-    […] I will see what I can do for you.”  -- Jörg Schilling
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20101121/1c5371fa/attachment.pgp>