QApt in Maverick

Almost home from vacation; another day in the car and I shall be home!

I’d like to take this chance to share what has been going on with QApt in Maverick, and what you can expect to see. While Muon will not be included on the CD in Kubuntu 10.10, once the “new” queue has been cleared out it will be available for install as any other application. More on that Wednesday, though.

What you will see in Maverick is the QApt Batch utility. This is a little application that acts as a batch installer/update application that other applications can use when they need to check for updates or install new packages without having to become a full-blown package manager. In Maverick, I have used QApt Batch to fix bug497803. If it doesn’t look too much like a bug, or even a problem, that is understandable.  Her is a bit of an explanation.

The original intent was to use KPackageKit to replace install-package, our batch installer utility. This (and GDebi-KDE) are two technologies that have been slated for removal in the Project Timelord plan due to lack of maintenance. KPackageKit was, however, not quite able to do all that we wanted with it, and also brought a lot of the KDE stack when it was used for installing packages in kubuntu-debug-installer. (What Dr. Konqi uses to get debug packages) QApt Batch is a drop-in replacement for install-package, its predecessor. It acts and looks similar as well, but with some marked differences:

Security

QApt Batch is safer to use than install-package was from a security standpoint. QApt Batch will inform you if you are about to install something from an untrusted source and either error out or ask if you want to proceed (depending on your APT settings), whereas install-package will merrily go along with the install without any concern. Best case, you just forgot to add the GPG key for some PPA. But worst case, you are being hit with a DNS cache poisoning attack or are in a country where the government cannot always be trusted, and you may be receiving a maliciously modified package.

Robustness

QApt Batch is also more robust in several ways. Primarily, it will catch and report more kinds of errors than install-package did. Being a python application, install-package always tended to have a RuntimeError or few hiding in the code, usually in the error handling… In addition, QApt Batch also handles debconf where install-package didn’t. This means that install-package would fall over on itself if it tried to install the Java packages, which have a Debconf EULA. QApt Batch handles debconf through libdebconf-kde. Furthermore, QApt Batch theoretically has Media switch (CD change) support. I say theoretically because I’ve not had the opportunity to test it…

Here’s a list of all programs in Kubuntu now using QApt Batch that were using install-package:

• Apturl-kde, which used install-package’s batch install features for the apt:/ protocol
• Kubuntu Notification Helper, which used the batch install features for installing proprietary addons, if requested.
• Language Selector, which used install-package for installing language packs.
• Software Properties KDE, which used install-package to refresh the package cache after you finished editing software sources.
• Kubuntu Debug Installer, which used KPackageKit to install debug packages and made installing any KDE app bring in KPackageKit/PackageKit in 10.04. 😦 The Kubuntu Debug Installer now uses LibQApt for seeing which debug packages need installing instead of hackishly using the output of “dpkg -s”
• Kubuntu Firefox Installer, which used install-package to install Firefox plus the KDE integration

All in all, quite a win for robustness, consistency, and optimization if I do say so myself.

I plan to look at my email once I get back from vacation tomorrow. (Or maybe I’ll look at it Wednesday) so please don’t feel offended if you’ve sent an email in the past few days and have not gotten a response as of yet.

See you all Wednesday!