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

[Richard Hughes]

2009/11/21 James Westby <jw+debian at jameswestby.net>
> Once the transaction has been setup, the client sends a message
> of "Register" to the o.d.Debconf well known name. It provides
> the nonce that it got from the transaction. The o.d.Debconf process
> now knows the clients unique name on the system bus and can hence
> talk to it.

I'm not sure Registering client is a good idea, it makes the whole
system a lot more complicated from a debugging point of view.

> Next the transaction is started, which may start a debconf process
> to get input. The apt backend arranges it such that this debconf
> process will run with a new "dbus" frontend. This frontend talks
> to the o.d.Debconf process and tells it what it needs (with
> appropriate access control).

Why access control at this stage?

> o.d.Debconf can watch NameOwnerChanged for the unique names, and
> tell the dbus backend to use non-interactive if the client
> leaves the bus. Lack of reply could be handled the same way, though
> this could leave a bad user experience where the user is promted
> with a question, but the answer is ignored if they don't answer
> quick enough.

Sounds good, although PackageKit already supplies "interactive" and
"background" hints; see below.

> There are various tweaks that could be made, but constraints
> such as the packagekit backend not controlling the debconf backend
> make it difficult to do too much.

Right, what limitations can you see from this?

> The big question in my mind is how this interacts with packagekit's
> notion of whether the client is idle. I'm not sure at which point
> we could read that information. Could you explain the ways that
> information can be read please Richard?

The transaction (and thus the backend) has background (i.e. not
important, not speed critical) and interactive (i.e. the use is
watching the UI, rather than something happening in the background
like a cron job). The backend currently pushes the interactive and
background variables to the helper process as part of the environment.
I guess it's easiest for the apt backend to proxy these to
org.debian.Debconf and then the service can make the appropriate
policy decisions.

Anyway, great you guys are working on this as well,

Richard