PackageKit in Fedora 11

Date	Status report
2009-05-14	Podcast up. Blog entry published.
Next action: N/A

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?

DBus is just a simple technology for one bit of software to talk to another bit of software. Before DBus existed, each application was an island, that wasn't really talking to anything else. When IPC (inter-process communication) was needed, we relied on hacky homegrown solutions like pipes and sockets, and overblown complicated IPC mechanisms such as CORBA and ORBit.

DBus allows any process to export properties, have methods, and emit signals in a standard way. I'll illustrate this using NetworkManager. PackageKit can call a standard method on NetworkManager to ask it to return all the connected connections. It can then examine the connection properties such as the type of connection on each returned object. NetworkManager also helpfully sends us signals when the connection state changes. In this way we can have all the networking data at our fingertips, without relying on lot of different shared libraries and low level hacky code.

DBus also has a cool trick up it's sleeve. You can make applications and services that only get started when a method is called on them. This is how packagekitd is started when a desktop application starts using PackageKit. In this way you're only running processes and using resources of things you're actually using. And also, when you've stopped using the resource, it can quit, freeing up system resources.

Using DBus, we can weave a web of desktop software talking to other software, so that things magically "just work". You can have empathy connect automatically when your network is connected, and have drivers installed for hardware as it is inserted. We're only seeing the start of what's possible in the future.

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?

Well, the fact that we have the source code to everything makes it trivial to add desktop-wide functionality, without negotiating with external ISVs to do different things. One example is the new mime installer. We wrote an automatic script that parsed the .desktop files contained in packages at rpmbuild time, and then added them to the binary rpm's as virtual provides. So the packages could have the right provides data, this necessitated rebuilding every single desktop package in Fedora, with a development snapshot of rpm. This just isn't possible with external ISVs and when you're dealing with proprietary code.

Another big advantage is that open source software normally does the right thing with external "value add" functionality. If I want to do notification bubbles I use libnotify, if I want to render fonts, I use pango, and multimedia I use GStreamer. This means we only need to hook into a few places for a lot of applications to magically work with these new features, without changing lots of code in lots of different projects. In my experience, this just isn't possible when proprietary applications either static link with old versions of libraries, or just hack up their own version for licensing or other reasons.

Now, I can't pretend that OSX and Windows don't have sweet features that we don't have in Linux yet, but I can say that the gap is narrowing, and now we're starting to have features like the auto-installing features that just are not possible in Windows and other proprietary operating systems.

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 last week I got married and this weekend I'm moving house, 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.

Audio interview

http://pfrields.fedorapeople.org/audio/pk-podcast.ogg (approx. 14 MB, 17 minutes)

Blog post text

In Fedora 11, we have a number of features that are the result of a planned process of maturation. We often put new features into the distribution with the purpose of garnering more information on how people put a technology to work. Then that information can be digested by developers to help them design and refine their software. It's a cultivation mentality: By focusing more attention on advanced technologies, we help them mature and improve faster. Including them in a popular, high-volume distribution whose mission is to advanced free and open source software is a natural strategic fit.

When PackageKit was first introduced to the masses, it was meant to smooth out the experience of someone using the free desktop. In Fedora 9, it provided mainly the functions to which long-time users were accustomed. In Fedora 10, the first glimpse of the longer roadmap appeared -- on-demand codec installation. In Fedora 11, fonts and some content types are also automatically handled for users. Entire applications are on the horizon.

As PackageKit maintainer Richard Hughes puts it, "Packages really aren't all that interesting" -- at least not from the user perspective. The idea is that people just want to be able to do what they sat down to do, without thinking about the plumbing of their system.

Listen to this podcast (INSERT LINK) in which Paul Frields, the Fedora Project Leader, interviews Richard about the motivation behind PackageKit, what's coming in the future, and the danger of oddly-matched clothing.