PackageKit

PackageKit aims to take the pain out of the package management on GNU/Linux systems and create a system that can compete with Windows and Mac. Development is proceeding at a rapid pace and it is set to be available in Fedora 9. To find out more, we talked to Richard Hughes , project creator, and Robin Norwood , the Fedora feature owner; as always, you can catch some screenshots at the end!

Digg it

If you enjoy this article, consider giving it a digg :)

Developer Interview

#!html
<div style="float: right; background: #eeeff1; border: 2px solid silver; padding: 1em; margin: 1em">

[[Image:JonathanRoberts_F9Interviews_PackageKit_Picture1.png]

Richard Hughes

Location: Guildford, Surrey, UK

Profession: Electronic Engineer (MEng)

IRC Nick: hughsie

Website: http://www.hughsie.com

Interviewed by: JonathanRoberts

#!html
</div>

#!html
<div style="float: right; background: #eeeff1; border: 2px solid silver; padding: 1em; margin: 1em">

[[Image:JonathanRoberts_F9Interviews_PackageKit_Picture2.png]

Robin Norwood

Location: Raleigh, NC

Profession: Coder

IRC Nick: rnorwood

Interviewed by: Jonathan Roberts

#!html
</div>

What motivated you to start the PackageKit project ?

Richard Hughes: Every distro re-invents the same type of package-management tools, and generally does it badly. Package management front ends are nearly always badly localized and translated as they are distro specific. Fedora has pup and pirut, Ubuntu has gnome-app-install and update-manager, and Suse has libzypp command line tools and the zen updater. The other distros basically throw some kind of GUI on top of the package tool rather than look at the use-cases and user interaction studies. To compete with Windows XP and OSX we need to improve what we offer for Linux, even with the wildly different systems such as gentoo with ebuilds and Fedora with binary rpms.

Robin Norwood: I couldn't agree more. Also, I'd add that application developers who want to install add ons but still play nicely with a distributions packaging system could benefit from a unified packaging API.

Could you elaborate a little bit about the work you've done with user interaction studies and use-cases?

RN: Personally, my only contribution to UI is to say what I don't like. I do know that, like a lot of open source projets, we could really use some UI/interaction experts.

How does it differ to the existing solutions?

RH: PackageKit works with distribution specific loadable modules and tries to abstract as much as possible between different distributions and packaging formats. GNOME and QT frontends talk to the daemon in a fully localized way, and do not require one "root" password to do most tasks.

The PolicyKit authorization to do tasks is fine grained, which means different users or groups can be authorized to do automatic updates, or install and remove packages. You can also run multiple instances of the front end tools without any "Another application is currently accessing package information" locking problems, and still continue to use the rpm and yum command line tools.

What work still needs to be done for it to reach a state where you feel its achieved its initial goals?

RH: The daemon needs to be faster. We are working on a new daemon where all interactions should be an order of magnitude faster. The front ends need to be complete and to comply to desktop HIG standards, and pushed upstream to be integral GNOME and KDE components. Projects like OpenOffice.org also need to hook into libpackagekit and use it to automatically install stuff like clipart if it's not installed.

RN: I think we also need to direct some attention to repository management. We have some tools, but it's not quite there yet. After that... polish. Lots and lots of polish. Making sure error messages are sensible, the UI is sane and helpful, and that everything Just Works.

That projects like openoffice.org will be able to work directly with the package manager is quite an exciting prospect. Has work started on this or is there much interest from upstream about this?

RN: I think it's something that a lot of application developers have wanted for a long time now, but we haven't really contacted them directly about this yet because we don't have all the tools and best practices in place quite yet.

RH: No, nothing yet. I'm hoping it will first be patched on the distro level like pulse audio was, and then pushed back upstream. I would imagine projects like scribus might be quicker to adopt this than openoffice.org.

How do you see this project in relation to others that have attempted to solve this problem, i.e. Klik (which has version 2 under development)?

RN: Well, first I should say I'm not terribly familiar with Klik. It looks interesting, but is a little bit different from what PackageKit is all about. The Klik idea seems to be 'one program, one file', sort of like Mac OS X's application bundles. This is an interesting idea, but it doesn't really work within the operating system's package management system at all. You have to have an entirely different system for getting security fixes and updates, for one thing. I have no idea how well the Klik folks have succeeded at this, but I think a solution that works within the powerful package management systems that Linux distributions already have is required.

Other projects, like Smart PM, take things from another angle. Smart tries to replace other package managers like yum wholesale. I think the problem you run into there is, until Smart or something like it replaces all of the features of the package manager it wants to replace, it will be almost impossible to get it into a given distribution. PackageKit sits on top of the existing package manager (like yum), which makes it a lot easier to gain acceptance. Power users can still drop down to yum and use that one magic feature that they must have that PackageKit doesn't provide a UI for.

I think PackageKit has it the sweet spot between those two options.

How's the work going on getting this ready to be easily available for Fedora 9?

RH: Well, PackageKit and gnome-packagekit are already in rawhide, and we've heard lots of success stories. All of the core stuff works with a mostly-complete yum back end, and now we need to concentrate on optimizations and front end user interactions.

Do you ever hope to see it taken up as the default package management system in Fedora?

RH: I hope so. We'll still need pirut in anaconda for package selection, but it would be good to fully integrate PackageKit like we've done with PulseAudio and HAL.

Has their been interest from other distributions about incorporating this?

RH: Much. PackageKit is shipped by default in Foresight Linux and the GNOME Developer Kit. There's also interest from Ubuntu, openSUSE, openSolaris, Mandriva, OpenMOKO and a few more that we can't announce yet.

And perhaps, to finish, you could tell us a little bit about yourselves? What got you interested in free software originally? What do you like to do with your spare time when you're not working with computers?

RH: Well, I'm 25 years old and graduated this year from Surrey University with a Masters in Electronic Engineering. I work for a large defense company in Kent, UK. I enjoy eating good food and playing football.

My first contribution to free software was a kernel patch to fix non-UTF8 encoding on CIFS shares, and then I moved onto adding power management stuff in HAL. I then created gnome-power-manager and OHM, and then finally PackageKit. I guess working on free software gives me the feeling that I'm doing something useful and special, and is a great way to work in dynamic teams of people who are among the best programmers in the industry.