In the good old days, the way you learnt about Linux was to build your own distribution and of course, design your own package manager as well. After all, what was the point of having your own distribution if you didn’t even write a custom package manager, right? As a result of that, package managers, packaging formats and dependency resolvers are a dime a dozen these days, in Linux. While most of them are as obscure as some of the distributions themselves, there are enough popular variations.
While we hail this as freedom and choice, this does have a cost associated with it. Users have to keep relearning the differences between software management tools. Not just distribution hoppers but also systems administrators who have to deal with different distributions all the time. Many applications developers would love to install additional software or content on demand instead of worrying about differences between distributions. Fortunately, yum install foo is not conceptually different from apt-get install foo. It is possible to abstract away the differences and provide a distribution-neutral interface for both users as well as developers.
Lo and behold! Enter PackageKit
Richard Hughes, a Red Hat developer, the maintainer of GNOME Power Manager and a contributor to other software such as HAL and DeviceKit, took a look at the landscape of graphical software managers in Linux a couple of years back and found that while each of them had their own advantages, they were essentially reinventing the wheel with their own quirks. And since distributions have a long history of investment in their own packaging tools, they weren’t going to give up easily.
He decided to develop PackageKit from scratch in a distribution-independent way. Now, after a couple of years of work, PackageKit is well on its way to becoming the standard software manager in the near future and is already the default in Fedora 9 onwards, while other distributions such as SUSE and Ubuntu are adopting it as well.
PackageKit is a tool designed to make installing, removing and updating software easy, and to provide the same graphical interface across multiple distributions. How is this possible? Before we get to that, it is important to understand what PackageKit is not. It is not a replacement for the dependency resolvers such as yum, apt or zypper. It does not do any dependency resolution on its own. PackageKit provides neutral interfaces for common functionality, such as installing or removing a package, which is mapped into the distribution-specific backends that take advantage of the native tools already in the distribution to do all the grunt work. The goal: in the near future, all distributions will share the same interfaces and for the most part you don’t have to worry about the underlying tools.
Before we move on, let’s take a quick look at the graphical interface shown in Figure 1. This one is the GNOME frontend.
PackageKit is a UI-agnostic library. There is KpackageKit under rapid development, which you can easily guess is a KDE frontend to PackageKit. They share the same common library.
As you can see in Figure 1, there is a fairly standard hierarchical view of packages in a Fedora 10 software repository. You can install software as a collection that is quite useful if you want all the packages that form the new LXDE Desktop Environment in one go, for instance. The filtering capabilities are a bit unique. Let me explain that a bit more. You can filter the applications that are shown based on whether they are graphical or non-graphical, for development or regular use, have been installed or not installed, and also whether they are free and open source, or proprietary.
The last part is interesting. As I noted before, the functionality is dependent on the underlying package manager. RPM stores the licensing information within the metadata itself and it is possible to sort and filter, based on this. Other formats like the one used by Debian do not. PackageKit enables or disables parts of the graphical tools automatically, based on whether the underlying backend supports it. So it is entirely possible to have a partially-supported backend in PackageKit and add more support incrementally. If you are a developer of a small distribution with its own unique package manager, writing a backend to hook it up with PackgeKit is much more effective than writing all the tools on your own, and this is exactly what many smaller distributions such as Paldus do, saving them lots of redundant work.
Major unique features
PackageKit is quite sophisticated and takes advantage of a number of new technologies. It integrates with PolicyKit, which allows a very fine-grained security model. I can, for example, give access to update my system to my family members but not let them remove any packages from it. PackageKit also has a daemon that is activated on demand and does not waste system resources. It is also session-aware and doesn’t break just because you end your session or have fast user switching to let another user log in.
Despite all this, PackageKit is fundamentally tuned to the basic needs of users and all the features are developed with this in mind. Recently, PackageKit added a number of new interesting features as well. Let’s briefly go through the major features that make PackageKit unique, very user friendly and way ahead of other desktop software management tools.
Easy run
When you install an application or a group of applications, PackageKit prompts you to run them. This is quite useful because non-technical users often are not able to find where the newly-installed application can be located. Linux desktop environments usually have a well-categorised menu, but PackageKit makes it even easier and more user-friendly. Refer to Figure 2.
Classification of updates
PackageKit classifies updates under security, bug fixes and enhancements, and you can choose to selectively update either interactively or set the preferences to automatically install them. If you are on a low-bandwidth connection, setting it to auto install security updates might be an ideal thing to do.
Environment aware—bandwidth and power management
PackageKit is aware of when you are using a mobile Net connection, and does not drain your bandwidth and increase your bills even if you have set it to update automatically (Figure 4).
It is also aware when you are running on battery, and it wouldn’t run updates by default in this case. The option to tweak this is an advanced setting not visible via the preferences dialogue box but you can change it via a GConf key.
Distribution upgrades
With the fast pace of free and open source software updates and many community distributions like Fedora coming up with new releases virtually every six months, users are often unaware that a new release is available. They continue to use old and outdated releases, sometimes even without getting any security updates, which leads to potential security issues.
PackageKit makes the process of upgrading to a new release just a bit easier. When a new release is available, PackageKit provides a notification on your desktop itself (Figure 5).
The upgrade process is managed by the native distribution tools. In Fedora, that’s PreUpgrade, which provides an online way to upgrade to a new release easily.
When a user initiates an upgrade, PackageKit downloads PreUpgrade and executes it. PreUpgrade then continues doing the actual upgrade process (Figure 6).
On-demand installation
In Fedora 10, PackageKit has a feature of adding codecs on demand. Let’s suppose you click on a music file, which is encoded in a format that doesn’t have support for it out-of-the-box. In most cases, previously you would get a cryptic error and you wouldn’t be able to do much with it. With PackageKit, there is a GStreamer plug-in and you get a nice descriptive dialogue box that guides you through the process (Figure 7).
Of course, you still need an appropriate plug-in, which is available in the repository. In the case of Fedora, you would need a third party repository like RPM Fusion enabled, but PackageKit will figure out the right plug-in all by itself. On demand installation is supported just for codecs now but much more is planned for future versions. More on this later.
Service packs—offline software installation
In Linux distributions, a rich choice of the software packages and updates is usually available in a central software repository, but not everybody has a broadband connection to get the software. And in India, this is still a common issue. It is only appropriate then, that an Indian participant in this year’s Google Summer Of Code, Shishir Goel, did the work to enable this particular feature in PackageKit. There are many command line utilities that can assist a user in this task, but they are often distribution dependent and cumbersome. PackageKit offers a very easy alternative in the form of service packs. Service packs are merely software packages and its dependencies wrapped in a standard tarball format. The user can select the dependencies to be packed using an additional option. Along with the dependencies, a service pack has a file named metadata.conf, which contains the distribution name, version and the date the pack was created.
For the command line junkies, pkgenpack is the command client that uses PackageKit to do the work. A simple example would be:
# pkgenpack --output=/media/disk/Rahul --package=xpdf
This generates a file /media/disk/Rahul/xpdf-fedora-10-i686.servicepack on my USB key. A friend of mine can take my USB key, go home, insert the USB key and double click on the service pack file to be prompted to install xdf along with dependencies included within the service pack itself. That’s just one example. You can do much more, including transferring updates. Do refer to the very well-documented man page for more details.
Future plans
This write up is based on the latest stable version of PackageKit and is already a bit outdated at the time of writing, since PackageKit is under very active development. It has a number of upcoming features planned or already available in the development versions.
The on-demand installation feature, like the one I hinted at earlier, is being expanded to cover more than just codecs.
Font support
Let’s suppose your native tongue is Hindi. If someone sends you a document in Hindi and you don’t have a Hindi font installed on your system, you would normally get an odd mix of characters that makes no sense at all. With newer versions of PackageKit, however, when an application opens a document, which requires a particular type of font that is not installed but available in the distribution’s software repository, PackageKit will automatically be able to search (Figure 9) and install it. So if you always wanted to read Greek love letters, here is your chance!
Mime support
PackageKit goes even further. What if you don’t have an application installed that can open the document in question? No worries! PackageKit can take care of that as well.
In Figure 10, PackageKit is asking to search for an appropriate text editor to open the document, but other documents or mime-types are supported. When multiple applications are able to handle a particular document type, you will be presented a list of choices to pick from with the distribution default shown first.
As you can see, PackageKit aims to enable users to move away from installing software just because they might need it some day, to installing software on-demand instead. There are many other new features in the pipeline as well, but time’s running out just now. We’ll talk about these another day, maybe. Till then, enjoy PackageKit and join us for questions in order to hack PackageKit at www.packagekit.org.
