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

[Daniel Nicoletti]

It's really fun how this far more complex draft was somehow
accepted by Colin, as Richard said this is a nightmare to debug,
and there is NO benefit to not use passthrough frontend,
my DBus frontend made in just two weeks accomplished all these
matters and doesn't even needed to worry about NameOwnerChanged.

Afaik Colin was on vacations, probably used that to go to UDS,
I really would like him to answer my last email about using passthrough
and doing a really simple change in debconf-comunicate would put an
end to all these problems.

Really, the solution is simple I just need an OK to don't
write code that does not get accepted

Best,
Daniel.



----- Mensagem original ----
> De: James Westby 
> Para: packagekit 
> Cc: Colin Watson
> Enviadas: Sábado, 21 de Novembro de 2009 16:37:56
> Assunto: Re: [packagekit] Debconf and PackageKit Was Re: Packagekit and Ubuntu
> 
> 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
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit



      ____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com