GNOME-PackageKit packaging

[Matthias Klumpp]

On Sun, 21 Nov 2010 18:45:58 +0100, Josselin Mouette <joss at debian.org>
wrote:
> 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?
Using the PackageKit API and/or accessing APT over a transaction daemon.

> 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.
PlugIn installation (e.g. Anjuta), Mime-Installation, Firmware installs
etc. For distribution upgrades you can use advanced tools, specialized for
the distribution's package manager or use the generic PackageKit.

>> 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.
You forgot the QApt stuff, which _again_ creates a software installation
daemon... At worst case there are APTd, PackageKitd and QAptd running at
the same time with Synaptic and other tools.

>> > 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.
Agree.

>> [...]
> 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.
Can you please point me to some points in the API which are yum/rpm
specific?

>> 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.
Okay, could you then please name the missing functionality? I'll talk to
Richard tomorrow explaining this. Usually, if there are good user cases and
if a change does not break existing stuff, he agrees adding more
functionality.

>> 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.
The PackageKit API covers all features I expect from package management...
In fact, the current implementation of Aptdaemon does nothing more at time
than PackageKit can do. The only stuff missing in PK is support for some
advanced APT features, like apt-pinning etc. But cause PK is cross-distro
it can never support features which are only available for one specific
package management.

> 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.
Ubuntu makes package management user-friendly. I'm in contact with the
Software-Center developer about these topics. In my opinion the best way
for everyone is to make PackageKit usable for Debian's purposes instead of
re-inventing the wheel and create new tools, which are tied to Debian.
(I've always been a friend of joint forces between the distributions) As I
said before, if you could name the missing stuff in PackageKit's API or
point me to the parts which are "wrong" ore need to be changed, I can talk
with Richard about the changes any maybe implement parts of them.

Thanks & kind regards
   Matthias Klumpp