[packagekit] PackageKit & Debian, Was: External dependencies, DeviceKit-power and GNOME Power Manager

[Martin Pitt]

Richard Hughes [2008-11-26 14:34 +0000]:
> On Wed, 2008-11-26 at 15:11 +0100, Martin Pitt wrote:
> > The only real question I ever needed to ask was for installing the
> > firmware for the b43 kernel module; while the kmod itself is free and
> > shipped upstream, the firmware isn't freely redistributable, and thus
> > you have to provide a source for b43-fwcutter (MacOS or driver CD, or
> > a download URL).
> 
> Right, ideally we can do this in an abstract way and get the GTK file
> chooser dialog for GNOME and the KDE one for KDE. I don't think asking
> the user for a path is the right thing to do.

I agree. Well, the entire b43-fwcutter setup is a Giant Big Hack, but
so far it's the easiest possible and legal thing we can provide for
those #)$*#$) Broadcom thingies.

> Right. Can you query the package before you install it to find out the
> questions you need answering?

For debconf, with using dpkg, -ish. You download it, and run the
.config script separately. Or you first only unpack it, and configure
the package afterwards. Either way, .config is a real (shell) script,
and can thus decide whether it needs to ask a question with
arbitrarily complex code, so statically deciding which question is
shown doesn't work. 

However, debconf is actually the easier case, you can even entirely
suppress it (DEBIAN_FRONTEND=noninteractive). Or write a new frontend
which collects those and does whatever with it.

The bigger problem are conffile questions, though. Fortunately those
are decidable before installation, by unpacking the package, checking
files in /etc/, and the md5sums of the current package.

> When we have the second pass, I guess we can install the package with a
> --firmware-file=/media/DISK/foo.fw switch and be silent. Would that work
> for you?

For debconf, answers can be "seeded" into the database, and thus
the questions won't be displayed. That doesn't work for conffile
questions.

> > So far this isn't blocking me enough to not use PK in Jockey (just
> > that silly dbus-glib bug [1] is driving me mad and prevents me from
> > using PK with its full capabilities).
> 
> That sucks -- I know not enough about dbus-glib to help on this one,
> sorry :-(

I had a long talk to Simon McVittie in Portland, and it is a complex
problem, so don't worry. :-)

My current nasty idea is to fork() in the backend, run PK queries in
the subprocess, and communicating with the parent process (which is
the jockey D-BUS backend) through stdin/stdout, using Python's cPickle
for data serialization. Yes, I know, efficiency nightmare, but I don't
have a better idea, it just doesn't work with threads or the async
API.

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)