[packagekit] Debconf and PackageKit Was Re: Packagekit and Ubuntu

[Colin Watson]

On Tue, Nov 24, 2009 at 11:20:47AM -0800, Daniel Nicoletti wrote:
> Ok, seems that you didn't get or read or anything my last email :P

Sorry, I'm afraid I've had trouble keeping up; when you dump a big code
tarball, that's likely to be the first thing I look at, especially when
you've previously complained about me looking at your design rather than
your code!

> But even simpler would be to
> call debconf-comunicate --create-socket=/tmp/debconf_002
> and let debconf-comunicate does exactly what aptdaemon
> does, listem and write to that socket.

Having looked at the aptdaemon code, I can see why you're asking for
this, and I don't think it's necessarily a bad thing to support in
itself (I might quibble about the option name or make it an environment
variable or something, but that's a detail). Certainly it would replace
a chunk of pretty ugly code in aptdaemon.

However, in the case of PackageKit, I'm concerned about having one set
of communications going over D-Bus, and some other set going over a
weird (in relative terms) side channel. It doesn't seem particularly
elegant, to my mind. You have to set up sockets with the appropriate
permissions anyway, and make sure that the rootly backend talks to the
right one, since we mustn't make it possible for the user to be tricked
into answering questions from some other process, or for some other user
to intercept the questions that the user running the PackageKit frontend
ought to be asked. Doing the same with D-Bus is hardly all that much
more work, and in some ways I think the security model might be easier
to analyse if it's all within the one transport system.

I actually rather like the notion of debconf being something you can
query over D-Bus given appropriate permissions, for a variety of reasons
not all of which are related to PackageKit. It's an important system
service on Debian-based systems, and there's something to be said for
exposing it in the new world order as well even if it isn't something
debconf has interacted with before. If the objection is because it's
harder to implement, well, in my mind, this isn't just a one-off
exercise.

> Why this is better than using DBus:
> - No new frontend or extending stable code

No new frontend needs to be involved anyway. We're talking a new kind of
thing at the level of debconf-communicate; it could even be an extension
to debconf-communicate, but since the code is completely different it's
easier to make it a separate program.

The only bit of stable code that needs to be extended is the passthrough
frontend itself, and that already supports multiple transports so the
extension is easy and safe.

> - Would probably be faster since there wouldn't be the DBus layer

I doubt that the transport will be a significant factor in debconf
performance, to be honest, nor that every millisecond of performance is
critical anyway when operations such as dpkg invocations are involved.

> BTW iirc there is a cmd line tool called kdialog which is pretty much like
> dialog, do you think it would be acceptable to use it or even write a new
> frontend like the dialog one so we can have a compiled kde4 frontend?
> (at least till perl-qt4 get's ready)

Yes, I think it would be reasonable to try to hack support for this into
debconf's dialog frontend, since it already has Xdialog support. It
might be best to make it conditional on an environment variable (like
Xdialog) so that unsuspecting people expecting a text interface don't
get stuck with it by mistake. Be careful of the way the exact details of
dialog command interfaces tend to vary a little bit.

I think I would rather it weren't a full-scale different frontend, since
we're going to want to obsolete it once perl-qt4 is ready.

It'll still be no substitute for a proper interface, but perhaps better
than plain dialog.

-- 
Colin Watson                                       [cjwatson at debian.org]