This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!

Feature: System Administration

PackageKit finds sweet spot in quest for universal package tools

By Bruce Byfield on June 25, 2008 (7:00:00 PM)

Share    Print    Comments   

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.

Bruce Byfield is a computer journalist who writes regularly for

Share    Print    Comments   


on PackageKit finds sweet spot in quest for universal package tools

Note: Comments are owned by the poster. We are not responsible for their content.

PackageKit finds sweet spot in quest for universal package tools

Posted by: Anonymous [ip:] on June 26, 2008 06:40 AM
I don't see what packagekit really does. The interface it provides is very similar to ubuntu's add remove programs app and os updating app, which is a heck load better than using synaptic for installing apps. This is just fedoras equivalent of what ubuntu has. So while i don't see packagekit being necessary for package management for absolutely other distros since ubuntu and linux mint have similar systems to what packagekit offers...kudos to fedora for jumping on the bandwagon for user friendliness and ease, and that's all that packagekit is good for. Once it gets more refined then other distro's that don't have app installation and update ease and friendliness (those that soley rely on synaptic or command line only) wouldn't be bad for them to adopt (i'm looking at you pclos).


PackageKit finds sweet spot in quest for universal package tools

Posted by: Anonymous [ip:] on June 26, 2008 08:45 AM
"This is just fedoras equivalent of what ubuntu has"

No. Just is a cross distribution interface developed by Fedora and Ubuntu is going to adopt it in the future too.


PackageKit finds sweet spot in quest for universal package tools

Posted by: Anonymous [ip:] on June 26, 2008 04:06 PM
Interface is not important, the underlying package format etc. should be standardized. .deb, .rpm and things like that should have a single replacement. PackageKit is an abstraction layer, some people also said it uses more resources than normal package management interface.


If you say so...

Posted by: Anonymous [ip:] on June 26, 2008 10:30 PM
I read through this whole article, and it says nothing. I am confused as to what PackageKit actually is or does. It apparently creates complexity where there should be none. Every time I read one of these "package manager to end all package managers" articles I am reminded of why, no matter how many distributions and package managers I try, I keep coming back to Slackware. It's simple, and it works. Note the keywords - 'simple' and 'works'. Hard to go wrong with those.


PackageKit finds sweet spot in quest for universal package tools

Posted by: Anonymous [ip:] on June 27, 2008 12:55 AM
"I read through this whole article, and it says nothing"

Oh, maybe doing some self research would help?


PackageKit finds sweet spot in quest for universal package tools

Posted by: Anonymous [ip:] on June 27, 2008 11:25 AM
This is nonsense. As someone else said, this is a re-invention of what Ubuntu already has. Maybe the architecture is better, maybe not. We shall see. The bottom line is that software like this is hard to write, because it's 70% usability and 25% corner cases and only 5% functionality. Ubuntu gets high marks for actually producing things that integrate with their distribution. I have no doubt this will work for Fedora and probably other non-Deb distributions, but until I see it working as smoothly as Ubuntu's native tools I don't see any value.

For those objection to abstraction layers... fixing the underlying problem is sometimes too hard because everything has to change at once. If you build a layer on top you can slowly transition to it, then swap the back-end arbitrarily without much trouble. I don't think that will work for package management, but it's a sound approach.


For those less-inteligent people here

Posted by: Anonymous [ip:] on June 27, 2008 12:41 PM
The article explains nothing. Go ahead and search for another info. Then you realize, that the ubuntu thing has nothing to do with packagekit.


PackageKit finds sweet spot in quest for universal package tools

Posted by: Anonymous [ip:] on June 29, 2008 06:25 AM
"Ubuntu gets high marks for actually producing things that integrate with their distribution."

Ubuntu produces pretty much nothing. They are a fork of Debian unstable repository after all. Most of the major innovations come from Fedora.


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya