It’s been a while that I was willing to starting posting about the Open Source projects I’m in, but as always time is short, and I have to decide between blogging or coding (as you might imagine most of the time I preferred coding).
So today I was thinking and trying to solve one of the problems in PackageKit vs APT and I thought maybe if blog I get some help.
Let me put you on the context then, I use Debian it’s my favorite distro for about 3 years and I really like Linux for Desktop, that’s why I got interested in coding Qt/Kde applications. About two years ago I finished my graduation in Computer Science with a project called doka (my first kde app), at that time multiple connections was not possible with the main Kde tools (Kget for instance), but with the advent of Kde 4 Kget got this support and Kget developers asked me to join them to not duplicate efforts. In the end of the year when doka was finally used for my graduation thesis I got an idea to improve KPackage (a Kde application to manage software using SMART) so I started to poking Kde people to find out how to improve it, and someone who I don’t really remember now told me about PackageKit and said that it would probably replace KPackage.
At the time I joined PackageKit dev team there was a QPackageKit interface that wasn’t working here and a python apt backend that kind of worked, but it was really hard to get all of it compiling since some code was based on experimental stuff and PackageKit was at 0.2 version. I was willing to help both QPackageKit and the APT backend since it was what I would use. Qt/Kde was easier to me than coding APT with python, so showing my ideas to Adrien the QPackageKit author we decided to split our work, I’d work on a new Kde interface and he would do a lib to talk with PackageKit, this way KPackageKit and PackageKit-qt started to get lots of code and are now used by a lot of users.
But it didn’t stopped there to have KPackageKit in Kde it was necessary to have a PolicyKit interface with Kde look’n'fell for it. The next step was to make PolicyKit-kde work, the original authors couldn’t help more and information on them was pretty rare, most Shaman devs joined and we formed a new PolicyKit-kde team, which got it’s code released by default in Kde 4.3.
Fair enough I want to have (K)PackageKit running on Debian (afterwards why would I code KPackageKit/PolicyKit-kde if I could not use it in Debian?), nowadays KPackageKit is quite stable so I started to focus on the backend thing. The APT backend had several problems which I didn’t like, it didn’t had packages descriptions localized, media change support, it fails if some package needs to install something that require the removal of other packages (quite common in Debian), it was eating too much memory imo, was hard to debug since if some python library was not loaded PackageKit fails with an unknown error, had some problems starting (fixed afaik), did not support enabling/disabling sources, configuration files are defaulted to keep the original and it fails to install some packages due to not have a debconf support. Some of these problems were already fixed, but at that time was one more motivation to start again from scratch.
Python is one of the languages I hate the most, and as I was willing to help with APT python was not a good choice for me, also APT was written in C++ and a C++ backend would make much more sense than a python one. I heard that someone tried to use C++ before but had some limitations (I could not believe that C++ would limit something), and the last point in favor of a C++ backend was that apt-get, aptitude and synaptic are all C++ applications, which are Open Source thus we can copy code from there and don’t reinvent the wheel.
Aptcc was born, I have to admit that the documentation of libapt-pkg is not good for a developer point of view, I took a lot of time to write the search part of it, but as I said having aptitude, apt-get and synaptic made this task not so hard, I must thank Daniel Burrows (nice name!) (aptitude author) for his time and patience helping me to get aptcc to start searching.
Search was done, and I started to fix all the problems I had found in python apt, I was actually faster than I thought it would be, with the help of the apt* tools source searching, getting details, localized descriptions, depends, was really easy. When the downloadPackage() method came to my list of TODO I realized that i had to find a way to add mediaChange support to PackageKit, Richard gave me a hand and we got mediaChange support in PackageKit. I got a bit busy with PolicyKit and KPackageKit so aptcc stopped with support of everything python apt had but install/remove/upgrade packages.
Recently I got a bit of time to start hacking again in aptcc, and in my mind what was most logical was to find a way to add support to remove packages while installing/removing/upgrading, this was a hard task since it would involve changing how PackageKit used to work, lot’s of ideas came and Richard denied most of then due to PackageKit policies, at the end simulate methods were created so we could simulateInstall, simulateRemove and be able to emit REMOVING, INSTALLING packages, this was also good since there was no way to get what would happen if a package file was going to install.
With simulate done my list of TODO is getting to an end, all is left is configuration files support and debconf, those two are the most complicated ones since PackageKit should not prompt the user without stopping the transaction, and debconf and conffiles run in the middle of an install and canceling it every time would be slow and easy to get some errors, also sometimes the user might start an install and simply logout his terminal, in this case where the debconf dialogs would pop up?
After lots of ideas discussions, a mail was sent to debian-devel mailing list, and the idea of a new debconf frontend became mature, which would solve all the problems plus bringing a new feature to debconf. The idea consist in having KPackageKit or GnomePackageKit to register a system interface to debconf, then pass the interface id to PackageKit which will pass to debconf, when debconf needs to show something it calls one of the client methods and display the question, if the client interface is not there it defaults to the Noninteractive frontend which solves the logout problem.
This last step is being coded at the moment of this writing it’s basically Perl + Net::DBus, if you are skilled with them and has the will to help, please join us at the packagekit mailing list.
If you liked the idea or have some improvements to it please speak up 
