Hi,
this is a reply from Hughsie regarding packaging API.
---------- Forwarded Message ----------
Subject: Re: PackageKit in Matahari
Date: Thursday, November 25, 2010, 10:27:13 am
From: Richard Hughes <rhughes(a)redhat.com>
To: Jaroslav Reznik <jreznik(a)redhat.com>
----- "Jaroslav Reznik" <jreznik(a)redhat.com> wrote:
Hi Richard,
we're working on Matahari [1] projects - in short summary - it's a set
of multiplatform agents exposing QMF/DBus interfaces remotely/localy.
We'd like to have very simple packaging agent in place. That means, we do not
aim
complex package abstraction layer as PackageKit is (for example
because of
Windows). But the question is - is it suitable to use PackageKit in this
scenario?
On servers where's no PackageKit available, we can directly talk
to yum but on
desktops (we have to support desktops in clustered/cloud environments too) -
we're
worried about interaction with PackageKit (as it usually used there
and
usually is running) and it can lead to conflicts - like locks etc. What's your
opinion, recomendation for us?
Hey, thanks for the email. Honestly, I think if you want to do a multiplatform
package abstraction, you want to be using PackageKit. PackageKit already
compiles on windows, although no backend already exists for windows currently.
It certainly wouldn't be hard to build a msi-based backend for PackageKit and
then it's a complete solution.
The obvious answer aside, is the more general point. If you have 'n' programs
all trying to use 1 non-parallel packaging framework (apt, yum, whatever) then
there is going to be be contentions and locks. You can't assume your project is
more high profile than other projects and just lock them out, for instance, if
Matahari is being used on a desktop, and the the user goes to use the command-
not-found feature in bash, the bash prompt will stall as yum has the lock in
another process. I believe the only way to deal with these limited "1 at a time"
resources is with a queued daemon, where different transactions are scheduled
according to the interaction mode and run with the desired latencies.
I think the correct thing to do, in my opinion of course, would be to use
PackageKit as the packaging abstraction and avoid re-inventing the wheel.
PackageKit has a ridiculously simple API compared to all of the other packaging
APIs, and I always fight hard to keep it that way; that said, if it's missing a
feature that people need we normally work pretty hard to get it supported on all
distros. I don't think you can design a package abstraction any simpler,
especially when it comes to returning localised results using user-specific
network proxies, and dealing with interactions like PolicyKit, trusted packages,
GPG and EULA dialogs.
Also, from someone that spend a lot of time looking at yum bugreports filed
against PackageKit, I would really advise against using yum directly. You really
have to hold it's hand at every step and keep a keen eye on the upstream yum
tree for API and ABI breaks. Long term I'm aiming to phase out yum use from
PackageKit and use a direct framework instead, just because of the constant API
breaks and unpredictability.
If you want, grab me on IRC, nick "hughsie".
Richard.
-----------------------------------------
--
Jaroslav Řezník <jreznik(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Office: +420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc.
http://cz.redhat.com/