[http://www.packagekit.org/ 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 [[RichardHughes| Richard Hughes]] , project creator, and [[RobinNorwood| Robin Norwood]] , the Fedora feature owner; as always, you can catch some screenshots at the end!

−

+

−

[http://www.packagekit.org: 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 [[RichardHughes| Richard Hughes]] , project creator, and [[RobinNorwood| Robin Norwood]] , the Fedora feature owner; as always, you can catch some screenshots at the end!

For more screenshots see this [http://www.packagekit.org/pk-screenshots.html website]

+

For more screenshots see http://www.packagekit.org/pk-screenshots.html

Latest revision as of 05:10, 9 June 2008

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!

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 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, 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.