Debconf support on KPackageKit

To mark the KPackageKit series of changes of 0.6.1 version I’ve very glad to announce that debconf support is now available and working quite well.

For those who followed the long story lots of people got angry/mad or something like that, because PackageKit”s design was not to ask things while installing. Sadly no one of the angry ones put faith into “working around” this problem or even fixing. There were flame wars and lots of people who didn’t ever put a hand on the code that said that PackageKit was broken by design (this wording is very common these days.. 😛 ).

Anyways it was sad that a project with the importance it had, would leave so big distributions like Debian and Ubuntu out of it.  Indeed convincing the author of it to do some changes wasn’t easy but in the end I must agree that most API breaks I didn’t cause were actually good. The author of PackageKit although some people disagree is really easy to convince that he is wrong when he actually is. And by that I found out that is VERY easy to say that something is broken or wrong but it’s hard to propose something that is actually good.

Before I started coding a new backend in C++ for PK (because I know nothing about python nor do I like it and I had to understand APT API to do somthing), we had 3 big problems with PackageKit:

1. instalation/update could not remove packages and remove operations could not install/update packages.
2. Cdroms and Dvds where also not possible to change
3. Debconf support was not possible

These were the blockers we had, the first two required a lot of thinking on how to break PK API and let the author happy, I must admit I got frustrated some of time, and almost gave up cause when I thought I had the perfect idea Richard (PK) showed the problems it could bring or that it wasn’t good enough 😛

But this story is about debconf isn’t it? So debconf problem was actually easier to solve than the first ones, the real problem was now to convince those who at first criticize PK to accept some solution. PK author said that a solution “out of band” (meaning something that didn’t change PackageKit but somehow uses another way of comunicating) was ok. So the first idea I had was to create a DBus frontend, this way we would not need PackageKit to make KPK and debconf talk, there is an old post here showing what happened (debconf devs didn’t like it), and after that I started thinking that if Software Center used debconf socket solution why would they be against it now? Talking to Michael Vogt (pretty nice guy) at UDS we decided that since debconf people didn’t bring any solution the easiest one would to use the socket frontend that Sw center uses too.

Sune once asked me why did I write that DBus frontend and a KDE client for it if Adept showed kde dialogs, he didn’t know how but I went to see it, yes today there is a perl+qt4 which allows us to have debconf+a qt interface. But he was right, Adept did have debconf kde4 dialogs because it actually implemented the debconf protocol (although not all of it). So the hard work was turn the code into a lib, get rid of non Qt code and to finish the debconf protocol implementation.

And that’s it now KPK has debconf support 😀

How does it work? Well if you’re reading till here you probably want to know that 😛 It’s simple. KPackageKit creates a debconf-kde instance ( DebconfGui() ), which receives a path to create a socket on /tmp the path is then passed to PackageKit which pass to the aptcc backend which sets an env var that debconf uses to communicate to debconf-kde.

Hope you all enjoy it 😀

“Give thanks to the LORD, for he is good; his love endures forever.” psalm 107:1