PackageKit support status

The entire purpose of PackageKit is to abstract out all the uninteresting packaging formats and tools into a coherent API that can be used by cool applications and tools in a cross distribution and architecture way.

Of course, this is limited by the distribution guys putting in the effort writing PackageKit backends for their system, packaging it up into packages, and then deploying it in new distributions to hapless users.

So far, we have quite a few distributions shipping PackageKit by default, and there’s every indication that a large majority will be shipping PK by the end of the year. Recently I’ve been very impressed with the work of Sebastian Heinlein integrating PK with APT. It’s been pretty difficult, as he’s been patching (rewriting?) chunks of python-apt so that the PackageKit API can be completed. For SMART, Anders F Bjorklund has also been writing huge chunks of code, which is also great.

Screenshot of some of the tools on Ubuntu (Copyright Sebastian Heinlein)

You can see how the other distributions are doing here.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

10 thoughts on “PackageKit support status”

  1. Minor pet peeve of mine: “OK” and “Cancel” do not mean “Yes” and “No”. When a dialog asks a question it should almost always give you “Yes” and “No” as options (with “Cancel” if aborting all action that would have happened is an option). Even better would be to use verbs (like “Install” “Skip” or something to that effect) and instead of asking a question, telling the user what installing the file means.

  5. That dialog in front is horrible. You are not going to install that file, you are going to install the program it contains. The dialog should show the program name and description and yes and no buttons.

  9. Wouter: it’s very difficult to infer the application name from the filename. It’s the equivalent to saying “do you want me to open this letter” — ideally you want to say “do you want to open the letter from grandma” but you don’t know who it’s from until you’ve opened it.

  10. You can open this file without install it, isn’t it? You can also open a letter of your grandma without to follow her instructions.

Comments are closed.