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

[James Westby]

On Thu Nov 19 16:50:50 -0600 2009 Sebastian Heinlein wrote:
> As a side node Colin Watson is working on making use of D-Bus for
> debconf.

Colin, a debconf developer, Scott, a DBus developer, Michael Vogt,
and myself, providing limited packagekit knowledge, discussed this
at UDS in a spare few minutes.

We hashed out an architecture for how debconf could be tunneled
over DBus such that a client tool could communicate with the
root process. It has some nice features, but I am posting it here
so that we can discuss how well it would fit in with packagekit.

Some background, debconf is said to have "frontends", but this is
not the split that you may think of. It runs as a single process,
the frontends just control the UI that it presents. There is a
"passthrough" frontend that allows you to make the split by
tunneling the protocol, which avoids the root vte widget.

The basic idea is then to run two debconf processes, one as root
and one as the user, and then tunnel the protocol over DBus to
acheive the interaction.

Note that one half of this, the "backend" debconf process is
spawned by a process which is a decendent of apt, so the packagekit
backend can't control it too much. This is not something we can
change.

The scheme we came up with was to have a activated process on
the system bus, named org.debian.Debconf here. This is a broker
that connects clients and the backend.

The transaction can be queried for a nonce that it is associated
with. We assume that only the process that started the transaction
can get this value.

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.

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).

The apt backend also places the transaction nonce in to apt's
environment, such that the dbus debconf frontend can access it.
The frontend then provides this to o.d.Debconf.

o.d.Debconf can then look up the client that is associated
with this nonce, and passes the message of what is needed on
to it (signals or a method call to the unique name would both
work).

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.

The client then fires up a debconf frontend running as the user
and speaks the debconf protocol to it and marshals the responses
back over Dbus. This part could be extracted in to a separate
process as long as it gets told the nonce.

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.

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? This scheme does handle
missing clients on its own, but does suffer from a permanent
blocking problem. (I think this is unavoidable as we can't cleanly
stop the maintainer scripts once they are started, but I agree
it is undesirable).

Thanks,

James