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!
If you enjoy this article, consider giving it a digg :)
#!html <div style="float: right"> <div style="background: #eeeff1; border: 2px solid silver; padding: 1em; margin: 1em">
Location: Guildford, Surrey, UK
Profession: Electronic Engineer (MEng)
IRC Nick: hughsie
Interviewed by: JonathanRoberts
#!html <div style="background: #eeeff1; border: 2px solid silver; padding: 1em; margin: 1em">
Location: Raleigh, NC
IRC Nick: rnorwood
Interviewed by: Jonathan Roberts
#!html </div> </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?
Kit 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 Package
Kit 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. Package
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 Package
doesn't provide a UI for.
I think Package
Kit has hit 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, Package
Kit 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 Package
Kit like we've done with
PulseAudio and HAL.
Has their been interest from other distributions about incorporating this?
RH: Much. Package
Kit 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 Package
Kit. 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 default software search screen for Package
The preferences screen for Package
Kit, showing the option to allow or disallow updates based on battery power
This screen demonstrates Package
Kit's abillity to work with Policy
Kit's ability to queue different package management jobs
For more screenshots see this website