GNOME-PackageKit packaging

[Julian Andres Klode]

On So, 2010-11-21 at 22:58 +0100, Matthias Klumpp wrote:
> 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.
Only one of them could run at the same time, as they all lock the cache
and dpkg status files.

> 
> >> > 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.
I do not agree here. Instead of creating one bloated application, it is
much better to create multiple small ones.

> 
> >> [...]
> > 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?
PkEulaRequired should be rpm-specific as far as I know. Instead of
establishing a scheme that allows configuration of any kind (such as
debconf), PackageKit only enabled the RPM-Specific EULA stuff.

> >> 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.
And if not, you can add it yourself as the maintainer. For example, you
could add a pk_package_get_debian_pin() to get the pin of a package.
Just make sure that every function you add includes debian in its name.

Upstream may not like you for doing this, but that's a sane way to
support our superior world correctly.

> 
> >> 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.
Oh, it could. If the backend does not support it, it just assigns 500 to
every package. Same with priorities: If your backend does not have them,
assign 'standard' to every package.


> 
> > 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.
The core problem I have with PackageKit is that everything goes through
D-Bus. But that's the price you pay if you are a pure level-3 (see [1])
package manager: You do not know if your backend has a cache or not.


[1]
http://juliank.wordpress.com/2010/10/20/the-three-levels-of-package-management/

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

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