On my last post I bloged about PackageKit and Debian problems, those that could be solved by creating DBus interface to bind Debconf elements using DBus, this way KPackageKit and Gnome-PackageKit could just implement Kde/Gtk frontends.
This was an easy task, I created a new DBus Debconf frontend which connects to some frontend using the system bus, it took about 2 weeks to write it plus a Kde frontend to test. I works quite well (you can see the screen shots below). I sent some mails to Debian Devel mailing list before and got some positive feedback, but when I talked with Colin Watson (Debonf devel) about this he didn`t like it very much, in resume his conclusions was that we would end up duplicating the existing Gnome and Kde frontends (which in kde case does not work in squeeze due the lack of perl-qt4).
Of course I got a bit frustrated since I created a simple solution that would solve our problems but seems like it was not the best idea, then talking with Michael Vogt (Synaptic) he suggested me to adapt this DBus code and make a proxy to debconf-comunicate. This is somehow what aptdaemon does, the frontend (KPackageKit for example) would start debconf-communicate get a DBus connection id and pass it to PackageKit when debconf need to say something the DBus Debconf frontend talks to debconf-communicate which would display the question using the current debconf frontends. This is a good idea since the complexity would be in debconf-comunicate, but this dbus layer would be a bit of a waste, instead of that I tought to extend debconf-communicate to create a socket and deal with it itself, so in KPackageKit or Gnome-PackageKit we would just need to call debconf-communicate wait till it return the path to the temporary socket file, which would be passed to PackageKit then to the Passthrough Debconf frontend.
Right now there is nothing implemented, I’m waiting for an answear to the mails I sent to debconf-devel mailing list, so I don’t code in vain again.
In the mean while I’ll do some improvements to KPackageKit 😀