Author: Bruce Byfield
Different GNU/Linux distributions provide incompatible systems for package management, and to date no one has quite figured out a foolproof way to get the best of them all. But where the alien utility tries to convert between major package formats, and Smart and Klik try to imagine new, universal forms of software installation, PackageKit has the more modest goal of supplying a universal front end that leaves the native package systems intact underneath. As Richard Hughes, the project lead for PackageKit, puts it, “PackageKit is a glue layer between the distro-specific parts, and some prettiness.”
In the few months that PackageKit has been under heavy development, many people have asked for more ambitious functionality, but Hughes has little interest in such efforts. The suggestion of alien-like functionality, he says, “is just insane, because the package formats are so different. They have different post- and pre-scripts, they handle gconf [the GNOME registry] differently — there’s just too many differences.”
As for the idea of a common format, he says, “That’s dead in the water before you get started, because just trying to get the distributions to agree on a common package name is impossible. Some want complexity, like Gentoo, and some want simplicity, like Foresight, so they all have a very different format. Trying to get one system to replace everything is just a non-starter.”
Getting started
Hughes started thinking about PackageKit in September 2006. “I was talking to my friends who said, ‘I switched away from Fedora, because that Pirut thing was crap,'” he recalls, referring to the distribution’s then-default graphical interface for package management. “And I looked at things honestly, and I though, ‘Yeah, this is crap.’ And I looked at other tools, and they were rubbish as well, so I thought, ‘How can I make things function better?'”
For the next six months, Hughes started thinking about the problem, and talking to Red Hat developers at GUADEC and other people interested in package management, and the idea of a universal front end emerged. Most people, though, were cynical, and Hughes could see their point. “There are so many different systems,” he says, “with scripts in Perl and in Python, and software in C and C++, and it seems such a mess. And they all have slightly different sets of rules and policies about them, so no one was really sure how you construct any of that, let alone all of it. And then I thought, ‘Can you make a system so that you can still use the existing tools and put a bit of cleverness on top?'” And, with that thought, PackageKit was born.
Meanwhile, Hughes was graduating from university and doing an internship at Red Hat, where he was working on power management for laptops. Some months later, Red Hat hired him to continue in the same field — and then the Fedora project decided to include PackageKit in Fedora 9. Suddenly, in early 2008, PackageKit went from a side project that occupied perhaps 10% of his working time and whatever pieces of his own time he could spare to his main concern, “just so I could get something out,” he recalls. “It just exploded.”
But, although Red Hat has supported his work on PackageKit, Hughes is quick to insist that it is not a Red Hat project. “They were very keen to have it hosted on their servers,” he says, “but I said that I wanted it to be an upstream project. Because I could see that could damage the project. Just the murmur that it might be a Red Hat thing might put a lot of people off using it.”
A show of interest by Ken VanDine and Elliot Peele of Foresight Linux gave PackageKit early credibility. Foresight was an early adapter of the Conary package system, which gives it a reputation for innovation. “They went through a lot of the API changes in 0.1.x, which really helped us form what PackageKit is, because Conary is so different from yum or rpm. Ken and Elliot have been really good about making us think outside the box.”
Now, with the widespread interest in the project, the chances of identification with a single distribution are vanishing. Although functionality has tended to arrive for the RPM package system first, equivalent functionality for other systems is rapidly following.
PackageKit today
Today, PackageKit works via packagekitd, a system-activate daemon — that is, one that starts when called and exits when no longer in use. Hughes says he made this design choice in deliberate contrast to Red Carpet, an early attempt at a cross-platform package installer first developed by Ximian, which relies on a daemon that remained constantly in the background, using system resources even when idle.
Once called, PackageKit communicates with native package systems via the libpackagekit library. “PackageKit has no idea what it’s doing,” Hughes explains. “It just takes the standard output of dbus signals or whatever, and then puts it out through the common API. So far as PackageKit is concerned, it just says do this, and the back end does it and gives the information about what happened back to PackageKit.”
Currently, PackageKit is available on the desktop only through a program called gnome-packagekit, although a KDE version is in development as well.
The version of PackageKit that shipped recently with Fedora and Foresight is the 0.1.x branch. It provoked some dissatisfaction on the Fedora List. Even though he was responsible for it, Hughes is brutal in his opinion of the branch. “It’s probably about three to four months old now. It can only work one package at a time and that sucks, and the gnome-package kit port, that was rubbish — it didn’t support EULAs [End User License Agreements] or anything like that. It’s a testbed to show that we could do what we wanted to do.”
Future directions
In contrast to his opinion about the first release, Hughes sounds optimistic about the 0.2.x developmental branch. “It’s much better,” he says, and overcomes at least the most crippling limitations in the first release. He expects the new release to reach the distributions using PackageKit by July.
One of the major changes in the next version will be support for GPG key signing, so that packages can be verified before users download them. While the details are still being worked out, Hughes is critical of current package signing, saying, “We can make the GPG signing suck a lot less. At the moment, we get a prompt saying, ‘Do you agree to key AF76 from this project? Yes or no?’ And most people just put ‘yes’ because they’ve never heard of the package name, and they’ve never heard of GPG. You can do a lot with that. For instance, maybe have a key that’s signed by PackageKit that says, ‘I know of the existence of these packages, and they are definitely [what they claim to be.]'”
Another improvement scheduled for the 0.2.x branch is simple structured prompts, so that users can, for example, answer yes or no in response to EULAs. However, Hughes says that he has no plans for allowing more complex questions such as those sometimes asked by debconf, the text-based system configuration tool used in Debian, Ubuntu, and other Debian-derived distributions.
“Those questions are just insane,” Hughes says. Talking with representatives of Canonical, the commercial face of Ubuntu, he recently heard an example of the sort of question that debconf sometimes asks at its most advanced setting. “The example they gave was, ‘load /user share application with Samba domain name in the installation phase?’ My argument was: I don’t know what my Samba domain name is — it just works. To people like my girlfriend or my mom, that means absolutely nothing. Most people would just choose the default. There’s about six people on the planet who understand it.”
Instead, Hughes favors a standard response script, like the ones that Ubuntu already uses in some packages. Those who want to respond to the more complex questions, he says, can still use debconf; PackageKit, he makes clear, is for the less advanced user.
For the same reason, Hughes will probably not add repository management tools to PackageKit in future releases. For one thing, such tools already exist in many distributions. More importantly, he is not sure that he wants to put the power to add or delete repositories in the hands of the average PackageKit user.
As Hughes sees it, the problem is that the more unsophisticated users want a package, the less likely they are to worry about whether a nonstandard repository is secure or might conflict with an existing one. “For example, if you have an Nvidia driver that keeps crashing, you aren’t going to care much about consequences if you see a new driver that’s available,” he says. “I’m not too sure about adding and removing yet. That’s providing an easy way to make the system really insecure. The sort of people who use PackageKit because it’s easy to use aren’t the people who will understand GPG signing or trust relationships, or anything hinky like that.”
Despite these reservations, within the limits of PackageKit’s audience, Hughes still sees room for future improvements. “I think there’s a lot of cleverness we can do without having to rewrite the PackageKit API,” he says, and he plans on a regular release schedule to help distributions coordinate their own plans.
But first, Hughes still has to adjust to the sudden interest in his once-private project. “It literally came out of nowhere,” he says, and similar phrases pepper his remarks on PackageKit. Although the project has been under heavy development for less than six months, as Hughes remarks, PackageKit’s goals are “in the sweet place.” The application is already being used in the Fedora and Foresight distributions, and efforts are under way to ready PackageKit for use with OpenMoko, openSUSE, Pardus, Pingwinek, rPath, and Ubuntu — though whether all these distributions will use PackageKit by default remains uncertain. If the project doesn’t provide the universal package system that some people dream of it, it at least aims for the more practical goal of a universal interface that hides some of the diversity.
Category:
- System Administration
