PackageKit in Fedora 11

Date	Status report
2009-03-17	Sent email to PackageKit maintainer asking to set up interview. Will try for print and audio interviews. Remember NOT to assume the audience already knows about the feature from last release!
Next action: Get answers to print questions, and set up for podcast.

Return to Category:F11 in-depth features page

Interviews

Print interview

I recently caught up with PackageKit maintainer Richard Hughes and asked him to talk a little about PackageKit -- how it came about, how it's been extended for the Fedora 11 release, and what's coming next.

What made you write PackageKit? What need were you trying to fill?

PackageKit is a system designed to make installing and updating software on your computer easier, as this process didn't really work well before. The frontends were literally just GUI wrappers around the underlying tools, and there were many design and security limitations with this monolithic approach. The primary design goal of PackageKit was to unify all the software graphical tools used in different distributions, and use some of the latest technology like PolicyKit to make the authentication process suck a lot less.

PackageKit also provides a D-Bus abstraction layer that allows the session application or user to manage packages in a secure way using a cross-distro, cross-architecture API. This means you can write a trivial application and install software without caring about what distro it's running on.

PackageKit was written mainly because nothing like it had been done before. In my opinion, managing software is a critical part of the Linux desktop where we want stuff to "just work" and not care about all the icky details about how the underlying system works, proxies, signing, and that sort of thing. Office applications need to install their own spell checker dictionaries, and video players need to install their own codecs when required. This stuff should just work, and previous arguments of "it's too hard" or "it's a political problem" are just not acceptable to me.

D-Bus is something a lot of users don't understand, but it has made a big difference in desktop functionality. Can you explain it simply?

<Answer>

PackageKit was first introduced late in Fedora 9, and replaced the old "Pirut" tool. There were inevitably some complaints. What happened during that cycle and in the Fedora 10 release to change minds?

Sure, in retrospect we might have introduced PackageKit too early. In Fedora 9 we continually updated PackageKit and gnome-packagekit based on feedback from real users, with real use cases. At the end of Fedora 9 and the start of Fedora 10, the UI was very different from what we envisioned at the start of the project, and the daemon was much more stable and feature rich. You could argue the reverse, that Fedora 9 and early exposure to users was a critical part in making PackageKit successful, as software designed in a sekret bunker and then released as 1.0.0 is never accepted properly by the community.

I like to think that as a maintainer that I listen to users, assess their requests and fix the bugs as quickly as possible. I don't think people minded too much that PackageKit was a bit rough around the edges when they knew the next update would make things a bit better. I've continued in this trend across Fedora 10 and in rawhide, fixing bugs and backporting new features where possible.

What new goodies can users expect from PackageKit in Fedora 11?

As a project, it's no secret we're slowing things down. In the explosive pace of development during the first 12 months, we were adding tons of code every day, and new features every week. As more of the initial use cases were being solved, we've moved onto integrating PackageKit into other applications and frameworks (Pango, GStreamer, nautilus, etc) and concentrating on daemon stability, speed and also reworking the UI to be more HIG compliant and user friendly.

So, for Fedora 11 you can expect:

• Speed increases in daemon startup and transaction scheduling, and increased stability of the tools and daemon
• A new update viewer, focused on usability rather than just maximizing the amount of data we throw at the user
• Installing applications when we get sent unknown file formats. If you get sent a .doc file and you've not got OpenOffice installed, Nautilus will now ask you if you want to install OpenOffice, Abiword or KWrite to open the file, all using PackageKit.
• If you try to view a Mandarin Chinese file in evince or evolution (in fact, any application using Pango), and you only get little boxes where the text is meant to be, you'll now be prompted to install fonts if available so you can view the document properly.

That sounds pretty significant. Do these features make the free desktop any more compelling than a proprietary desktop like Windows or Mac OS?

<Answer>

Do you have any plans for Fedora 12 and beyond?

We really want to look at how actual users interact with the tools, for instance reducing the number of modal dialogs, and removing flashing text and icons. Matthias and Jon have been doing fantastic UI reviews with the update viewer, and I hope this will extend to the other tools in F12.

I also want to look at installing "applications", as well as packages. This is much better from a user point of view, although might be tricky to do in a cross distro way. Hopefully there'll be a GSoC student working on this in the summer which may kick start things.

PackageKit's intended to be a cross-distribution solution, so users have a smooth experience regardless of their distro of choice. How is the uptake in other distributions on PackageKit? Are distros including it, and using it as a default?

Well, Fedora, Suse and Foresight have always been the early adopters. I'm pretty sure those three are all using it by default now. Ubuntu are shipping PackageKit now, but I don't think they are using it by default yet -- but the DBUS API's are available. OpenMoko is currently using an old version on the mobile phones. Mandriva 2009 is also using it, although they've only just finished the integration work, so it's not quite the default "application" yet. Quite a few of the smaller distros like Pardus and Pingwinek are using it by default as they don't have to commit resources to building a distr-specific tool, which I think is great.

Are there alternatives out there for providing some of these new PackageKit features?

Well, I'm sure you could hack up some code to do things in a yum or apt specific way, but you would need the root password and it would be pretty horrible. If you mean Red Carpet, the project is long dead, and tried to do the core bit of PackageKit with an enterprise focus and a static daemon doing RPC. It also only supported .rpm and .deb, and replaced the depsolving in yum which wouldn't have been popular in distributions. It didn't do any of the clever integration stuff PackageKit is currently doing.

What do you do when you're not hammering away on package management front ends?

Ha! Power management frontends! Seriously, I've been working hard on DeviceKit-power, the new PolicyKit, and the new gnome-power-manager. I seem to have my hand in lots of different projects right now. I'm also doing some kernel stuff, and still breaking keyboard mapping and fixing resume failures.

Geeky aside, I like to keep fit, but mainly my fiancee and I are planning a wedding, which is taking a fair chunk of our fair time outside work. I also like to do a bit of amateur photography, although I'm not very good just yet.