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:
- instalation/update could not remove packages and remove operations could not install/update packages.
- Cdroms and Dvds where also not possible to change
- 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
17 thoughts on “Debconf support on KPackageKit”
Thanks for persevering. This will be a good thing!
Awesome that KPK has debconf support, but honestly I have no idea what the arguments/discussion about it were. I can’t make this out of your story.
Well I didn’t come into details cause I don’t want to make more case than were already done, It’s done now and it works 😀
Really cool – but will it be available in Debian and GNOME-PackageKit too? I think it’s time to get PackageKit into the Debian repos, but it seems like noone is interested in woring at it at time.
By the way: Why doesn’t Ubuntu use the aptcc backend as default? My first impressions of it were that it’s much faster than the original Python apt backend. (And I don’t really like Python too :-P)
To be available in Debian they need to want it, which seems not to be the case…
GNOME-PackageKit just need to be patched to use debconf-comunicate and the gnome debconf frontend.
In Maverick aptcc is the default. The main advantage of aptcc over the python one is memory usage,
and when the repos you set have lots of packages it is faster. Apart from that some methods are more intelligent too like when you search for a virtual package instead of giving nothing to the user aptcc sends what it provides (the search is case insensitive, it does OR by default, and it search into localized descriptions too and still a bit faster), it also emits the speed of download and the individual download/install progress which lots of users complain by not seeing it.
I have measured once getting all the installed/available packages and aptcc took 30 seconds to process all of it while the py version 50s, but for small searches it’s harder to see the difference.
The Debian devs definitely want PackageKit in the repos. (I doubt they will set it as default, but the repository is open for every application)
See bug #468132 for the ITP ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468132 )
I talked with Sebastian Heinlein some time ago and he said he does not want to upload the PackageKit package at time because some devs have “strong feelings against it”, which were against the missing Debconf-Support. (AFAIk this was the reason why Ubuntu’s SoftwareCenter does not use PackageKit and why AptDaemon and QApt were developed)
But now, since PK has the missing functionality, it should be no problem to have it in Debian’s repos. I left a comment on the ITP, but did not receive a reply from Sebastian yet.
To aptcc: True, Maverick uses aptcc… I haven’t noticed the change cause I’ve set my own configuration… I develop an application which does a lot of SearchFile queries to PackageKit (over 20 sometimes, I’m working on a smarter solution for the next release). If I use aptcc, the process finishes in half of the time apt needs for this. (I haven’t saved the accurate values, but it needed 48% less time (on 4 parallel queries at time), I think. Yum was the fastest backend ^^)
Yes, probably now they might like it, one reason some Debian-kde don’t want KPackageKit is because random applications can ask it to install things (but it can be disabled with simple patches).
> I think. Yum was the fastest backend ^^)
Really? I think it might be fast for file searches then because all the tests I did with yum were VERY slow.
I did the tests last year, so I don’t know the exact results anymore. (Also, my Fedora machine was a bit faster when I did the yum tests. The searchfile command depends a lot on disk speed, also the file system (ext3/4, btrfs) changes the results)
Anyway, about the Debian inclusion: I now took the job of bringing PackageKit to Debian, we’ll see if they accept it.
Does debconf support mean, that if KPackageKit can now remove conflicting packages to fix dependencies?
Because I have always had to resort to Aptitude when it can to automatically removing conflicting packages.
No, debconf support means that when you install packages and these packages have questions to answer you can now answer them.
Like when installing sun-java you will be prompted to accept it’s EULA.
the packagekit-backend-aptcc does exactly the same thing that apt-get would do (including removing packages to install others), but sometimes aptitude is a bit smarter than apt-get so you might (hopefully not) need it a few times.
Aha, so debconfig is for answering questions, such as license agreements!
That really helps me understand the usefulness of its addition, thanks for explaining. (it might even be worth adding to your post. 😉
Well yes, in the past I had to use aptitude in order to delete a long list of conflicting packages, that KPackagekit (or perhaps the apt-cc-backend) was not deleting.
KPackagekit simply said something like ‘Error could not install because of a conflicting package.’
I’m running Kubuntu 10.04 if you were curious.
Just wanted to thank you for fixing this issue. Hopefully this will make a way for PackageKit (and KPackageKit) to soon get into Debian.
Thanks, that’s my wish too 😀
Packagekit is now in Debian Unstable. 🙂 http://packages.qa.debian.org/p/packagekit.html
Yes I know pretty nice 😀 now someone needs to package KPackageKit 🙂
[…] to Richard Hughes and Daniel Nicoletti. Daniel found a way to make use of Debconf in PackageKit and implemented it in KPackageKit, and Richard Hughes did the last steps to make pkcon and GNOME-PackageKit use the new Debconf […]
[…] Daniel hat einen Weg gefunden, Debconf in PackageKit zu nutzen und hat diesen auch gleich in KPackageKit implementiert, während Richard Hughes, der Erfinder von PK, die letzten Codeteile geschrieben hat, um das […]