Introducing QApt and the Muon Package Manager

It has been a while since I’ve blogged. I know I said I would post stuff  about something exciting at UDS, but that sort of never happened. 😦

But! Better late than never. I think that waiting a month or so has also made this post better than it would have been at UDS. Before I do any introducing, I feel that a summary of the history of KDE/Debian package management is in order.

A Brief History of Debian-based Package Management in KDE

It can be said that the hardest part of writing a package manager is not in writing the GUI, but in interfacing with the package system. For a long time, this has been the biggest barrier that has limited the number of Qt/KDE package manager for Debian-based systems. Even among those that do exist, such as Adept and PackageKit, each interfaces with your computer’s underlying package system differently, each with its own set of bugs and unique, not-always-equal feature set.

These factors combined have caused a drought in the number of Qt/KDE packaging systems from the earliest days. When these package managers were good (like Adept 2 in KDE3 days), things were generally fine, and the drought had a limited effect. The transition to KDE4 threw package management GUIs right back to square one, and even two years later there has not been a replacement of the caliber of the KDE3 package managers.

But what if there were a way to alleviate both of the factors contributing to the lack of stellar package managers? What if all Qt package managers for Debianish systems could share one underlying library to interface with the system package cache? What would happen if the success of a package manager was not limited by the difficulty of writing a low-level package management backend, but rather was solely dependent on the quality of the user interface?

Introducing QApt

QApt is the answer to the above question. I had pondered the above questions for quite a while, starting back with the inception of the Project Timelord initiative.

A bit later, the Shaman project was announced, and I was interesting in writing a backend for Shaman. There was already an APT backend for Shaman, though it was in its infancy. That’s when I realized that libapt-pkg was an ancient dinosaur with an awful API. That’s when it dawned on me that I could write a library/backend that any Qt or KDE application could use to manipulate/read the Debian package cache.  If a focus on this potential library could be made, then any Qt or KDE application could use it, from Shaman to a “Software Center” style app to a completely custom, fully-featured package manager.  Developers would be free to focus on making a great GUI, and could all share the same internals.

I started three months ago by spending a few days trying to grok the libapt-pkg API by looking at the internals of Synaptic, the APTcc PackageKit backend, and the python-apt bindings. After a month or so of hacking, the result was QApt. Then came finals season and UDS…

But what is QApt? QApt is actually split into several parts. Half of QApt is LibQApt, which is a Qt wrapper around libapt-pkg that boasts a saner API, as well as a pretty extensive APT cache implementation for fetching information about packages. This constitutes the read-only portion of QApt. The second half, the QAptWorker, is equally important. The QAptWorker is what does all the dirty “needs admin” stuff, and could be considered the “write-only” portion of QApt. It handles everything from checking for updates, doing the package downloads, and actually installing/removing packages. LibQApt interfaces with the QAptWorker over Polkit, giving all the normal security and sysadmin-flexibility of the PolicyKit framework. Apps using LibQApt do not have to run as root, and sysadmins can exercise fine-grained control over which operations they let their users perform.

In addition, QApt ships with a simple batch installer utility called “qapt-batch”. It is a drop-in replacement for install-package, which is a utility that several Kubuntu applications use to install packages from non-packagemanager applications. (E.g. codec install, the firefox installer, apturl-kde, etc) It already has a few neat features that install-package does not, including more informative error handling, security improvements (warn about unsigned packages, etc) and media change support.

For further technical details, you can see the slides from the UDS presentation on LibQApt that I did here, and the neat little diagram I made with umbrello here.

What uses QApt?

At the moment, two external projects use it. There is an infantile Shaman backend based on QApt in the shaman svn branch that can do your basic things (install, remove, check for updates, error handling, etc).  Check out playground/libs/libqapt, install, and you should be able to build the shaman backend.

In addition, I wrote my own package manager, Muon, which I shall spend the rest of this post discussing.

Introducing Muon

Muon is a package manager based on QApt that I started to write about two weeks ago, when I felt that LibQApt was extensive enough to be able to write a package manager with. It follows in the current KDE naming fad of naming your app after a subatomic particle. The purpose of Muon is to cater to the usecase ranging from “user who knows a fair bit about how his computer works but really isn’t a terminal-lovin’ power user” to the “poweruser” usecase. Its goal is to have all the power of the end-all of all Debian-based package managers, Synaptic, while at the same time presenting this functionality in a more usable fashion than Synaptic. It’s never going to be a “Software Center” in terms of  “Your non-techie family member could use it”, but that’s OK; thanks to QApt, writing a Software Center-style app would be just a matter of writing another GUI shell. Seeing the amount of progress I made in two weeks, this is definitely not something to worry about. (I also plan to write a Software Center/Adept Installer style app once Muon has a stable release)

Currently, Muon sports a quite spiffy feature list. (Especially for a two-week old package manager!)

• A powerful, yet intuitive interface
• Fast, accurate package search using the apt-xapian index and the Synaptic search algorithm
• Support for filtering packages by status and category
• Media change support
• Support for configuring packages through the debconf system
• Warns about/disallows the installation of untrusted packages, depending on APT settings
• Uses Polkit for running privileged actions for enhanced security, convenience, and desktop integration
• Power management suspension during package downloads, installations and removals
• Support for download the latest changelog of a package
• Package screenshots

But, talk is cheap. Bring on the screenshot tour!

Here we see the initial view of Muon. (Click all screenies to enlarge.) Pretty straightforward. Toolbar on the top, filters to the left, search bar/package view to the right.

Here I’ve searched for Konversation and clicked the first result. A details tab bar popped up as a result. The first tab houses the short description, a button to fetch a screenshot, buttons for marking konversation for removal, purge, or reinstallation, the long description, and finally a short blurb telling how much longer Canonical will support konversation. (Since it’s in main)

Unfortunately, screenshots.debian.net lacks a screenshot for Konversation. 😦

Dolphin has one, though.

I couldn’t fit all the details in the first tab, but the second tab has a bunch of neat technical details.

Here we can see Konversation’s dependencies. For packages that provide virtual packages, you can also view those packages by selecting “Virtual packages provided” from the combobox. But Konversation doesn’t provide any virtual packages, so this screenshot can’t show you.

The changelog tab. (Hey, that’s me! :D)

Since I already have Konversation installed, I can see what files the package has.

Filterting by category works.

You can filter by category and by status at the same time. In this picture, I am filtering on installed KDE packages.

After I marked amor for installation, I hit the  “preview changes” button in the toolbar, which graciously shows all packages to be installed/removed, and turns the preview button into a “back” button.

Gotta give my password before I can hit apply. (Polkit remembers the password for a few minutes, so you can install/remove something again directly after this install without being annoyed by the dialog again.)

Downloading. This could stand some improvement, (Per item progress, get rid of the URIs, etc) but is functional.

Installing amor. It happened so fast that it was already cleaning up by the time ksnapshot could get a picture. 😉

If the need ever arises, a debconf GUI shows up. Please don’t mind the Debian branding. That should change before any stable release. Muon uses the Debconf KDE Library written by dantti, which should hopefully also be usable in the next version of KPackageKit. 🙂

Untrusted packages, while usually just a matter of forgetting to add a GPG key for a PPA, are a security concern. (E.g. DNS Cache poisoning attacks…) It does follow APT configuration, though, and will totally disallow installing unsigned packages if that is set in /etc/apt/

Muon also asks if you really want to remove that essential package

..and also prevents you from making changes that would break the package cache, like any good package manager should. (It undoes the attempted change after you press OK)

For all its features, Muon and QApt are not yet, in my opinion, ready. They still need support for showing reverse-depends, package downgrade and pinning support, and in general just need some more polishing and bughunting. Muon still is only two weeks old, you know. For this reason, I’m going to say right now that this will not be the default package manager for Kubuntu 10.10.  Every single time we’ve jumped on the latest-n’-greatest piece of package management shininess, it’s never ended well. Adept 3 was decent in my opinion, aside from search accuracy and a somewhat scattered UI, but it was rushed to be made ready for release and really never stood up to the quality that Adept2 provided. Similarly, K/PackageKit was still young when we picked it up in Kubuntu 9.04, and while in 10.04 it’s not the disaster it was in 9.04, it’s still not as nice as a package manager could be. So let’s just let Muon and QApt cook for a while, and then we can see where we stand for Kubuntu 11.04. It’ll be worth the wait. 🙂

In the meantime, I plan to go through a prerelease cycle for both QApt and Muon. It is conceivable that at the least qapt-batch could be made ready to replace the python install-package for Kubuntu 10.10, but aside from that nothing big will come. I do plan to make packages for both QApt and Muon available for lucid and maverick throughout the prerelease cycle.

You can grab Kubuntu packages of the first alphas of both Muon and QApt from my PPA for both lucid and maverick here. Muon should also build and work just fine on Debian, but I don’t have packages for it. It requires Qt 4. 6 and up, so users of Debian unstable should be able to build and use it from svn just fine. (muon is in /playground/sysadmin/muon) Tarballs for QApt 0.2 (1.0 alpha1) and Muon 0.2 (1.0 alpha1) can be found here and here respectively.

Please beware that while things should in theory be safe, Muon has not yet had widespread testing, so there is still the slight chance that a bug could still be lingering, ready to kill your kittens. Just keep that in mind, and have fun. 🙂 I look forward to feedback on Muon, and will continue to work on improving both Muon and QApt for a brighter future for package management.

Oh, and does Muon go moo? It might. 😉