[Debconf-devel] FWD: Debconf Dbus frontend and PackageKit

[Daniel Nicoletti]

>Michael Vogt wrote:

> 
> On Tue, Oct 27, 2009 at 09:58:17AM -0700, Daniel Nicoletti wrote:
> > > Hi,
> Hi,
> 
> > > I've talked to Colin on irc and we discussed some
> > > things about the PackageKit integration with debconf.
> > > The main problems we have is that the user in PackageKit
> > > can start an installation and logout, in this case the
> > > frontend must fallback to noninteractive to avoid problems.
> > > 
> > > After long discussing with Richard he agreed to
> > > either have a Dbus interface or a setting up a socket
> > > to deal with it.
> 
> Thanks for working on this, I think its great that PK can finally get
> debconf support.
> 
> > > As someone said in debian-devel list having a Dbus
> > > frontend would make most sense since PackageKit
> > > is Dbus based.
> > > So in 2 weeks I created a Dbus frontend, with a simple
> > > interface, I have even created a kde4 interface which
> > > debconf currently does not have due perl+qt4 binding.
> > > 
> > > After talking with Colin he stated that using Debconf
> > > Passthrough frontend through a socket would be the
> > > "only" way to it, since Dbus.pm would "duplicate"
> > > Passthrough.pm and also the gnome/kde interfaces.
> 
> I looked at the attached code now and while I quite like the approach
> I think Colin is right in that it duplicates functionatliy and that it
> also duplicates the frontends. This is not ideal IMO.
> 
> > > All Dbus.pm/Kde4 is attached if you guys want
> > > to take a look*, now as I want PackageKit soon on Debian
> > > I'd like to know which way you guys suggests me:
> [..]
> 
> How about the following solution. Extend the passthrough interface so
> that it honors "DEBCONF_DBUS_BUS" (just like "DEBCONF_PIPE") and
> creates a dbus debconf proxy at org.debian.Debconf on a private
> bus. The only exposed method is called communicate() that just
> sends/recives a debconf protocol string over the (dbus) wire and
> returns the debconf answer. The PK daemon setups the environment so
> that "DEBIAN_FRONTEND=passthrough and DEBIAN_DBUS_PIPE=bus-name". When
> apt/dpkg spawns debconf it will be run and tries to connect to the
> dbus object apt.debconf.DebconfProxy
> 
> In the client debconf-communicate is wrapped (or extended) so that it
> creates a private bus (the name then need to be passed to the PK
> backend) for org.debian.Debconf and provides the communicate()
> method. If there is a debconf question, the PK backend passthrough
> will call communicate() and pass the debconf message. That is passed
> via debconf-communicate, processed and the answer is send back. This
> should work mostly like the current socket interface but the
> communication should be somewhat less low-level than using a plain
> socket. It also means that debconf-commnicate spawn the right frontend
> (gnome, kde when it becomes available or even text,dialog if someone
> wants to use pkcon). 
> 
> What do you think ?
The only problem this still have is that we can't easily write frontends
like gnome/kde, as for the later we still without one because we rely on
perl bindings, if we use my Dbus frontend the kde is done in C++.
But as we talked earlier I think what we could do is to extend debconf-communicate
to do all the socket handlying itself thus making it possible to just call it
in gnome-packagekit and KPackageKit passing a non existent socket
path:
debconf-communicate --socket-path
if it could not create the socket it could return a non zero value
other wise we pass this path to passthrough.
This imo this is the best solution to avoid frontends duplication
and make the job of ui easier and not duplicated too.

What about that, can i code it?
(don`t want to make the same mistake twice :P )

Daniel.


> 
> Cheers,
> Michael



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