Tag: PackageKit

PackageKit Collections

From PackageKit 0.3.3 onwards, a new type of package is supported called a collection.

 What gpk-application looks like with collection support

A collection is a metapackage that can represent a group, where the package mapping is done inside the backend. It is not like a catalog where an external file provides a meta-group. This enables the “group install” and “group remove” functionality people have been requesting since version 0.1.0, without get another abstract group mapping or extra API to support.

I’ve made a few changes in the daemon to properly support this new type, and in the yum backend Tim Lauridsen has added support using the comps group mapping. Mike Langlie has drawn us some great icons, and Anders F Björklund implemented collections for smart, and helped us with the design process. The extra type should be trivial to add to other backends too.

We added the feature in just a few hours of hacking, as everyone was working together. I’m amazed at how people work together so well all over the globe, in different timezones and with different work priorities – thanks guys.

Comments, as always, appreciated

PackageKit Web Plugin

Owen Taylor has been rocking recently. In the 0.3.x releases there’s an optional packagekit-plugin package that is a standard Mozilla plugin. It works in Firefox and Epiphany and looks something like this:

Test page shipped with PackageKit

It’s actually pretty easy to build a website that wants to install something new or run an application that is already installed.

The actual html you need is something like this:

<object type="application/x-packagekit-plugin" width="500" height="200" class="packagekit-plugin">
<param name="displayname" value="KStars"/>
<param name="packagenames" value="kdeedu kde4edu"/>
<param name="desktopnames" value="kstars"/>
</object>

You can omit displayname and desktopnames if you wish, as PackageKit can query the backend and fill in the blanks. The packagenames are queried until PackageKit finds one that matches on your system.

I’m also thinking about adding the application icon in the box as common applications usually have standard icons that PackageKit already uses for other stuff.

Of course, because this uses PackageKit, it’ll work on any distro. If you want to improve the look of the plugin or add some extra features, jump on the mailing list and give ideas. Feedback welcome.

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.

PackageKit 0.3.x new features

PackageKit development keeps on trucking. After the ServicePack functionality was added in 0.3.0, we’ve got the GetDistroUpgrades functionality in the soon to be released 0.3.1 The latter allows us ask the backend if there are distro upgrades, for example, when Fedora 10 is released. By default we check for this one a week.

I’ve not really thought about the UI for the notification (and traditionally I suck at UI design), and so I welcome advice and comments from you guys. I’ve got this so far:

gpk-application multiple package selection

In 0.1.x PackageKit had a restriction it could operate on only one package at a time. This sucked for a multitude of reasons, the main one being that to install a few packages you had to wait for the preceding one to finish.

In an ideal world, we could still query a software list while we are updating, but a lot of the backends do not allow that, giving unpredictable results or ‘just‘ corrupting caches.

One of the main feature requests for 0.2.x was to handle multiple packages in one transaction. The API was slightly changed in PackageKit to support this in 0.2.1, and now the client tools like pkcon and gpk-install-package-name all accept more than one package at a time. Yay for the command line.

This left gpk-application, aka “Add/Remove Software” – which was much trickier to do in a sane way. Now, I’m not saying the screenshot below is sane, but it certainly works, and we can improve it in the few weeks before 0.2.2 is released.

Comments welcome.

KDE love!

Recently, Daniel and Adrien have been rocking with KPackageKit and QPackageKit.
The library is coming on nicely, and the tools are starting to look very KDE like. They could do with a hand, so if you want to get involved, jump on the mailing list and introduce yourself to those two dudes.

See here for a sneak preview. There’s also a screenshot of the OpenSuse updater, which is also working with a PackageKit backend now.

Next step, world domination. Seriously, rock on.

How about something like this?

Okay, I’ve added the needed stuff in desktop-file-utils for the yum backend to pick up the virtual mime-type provides in rpm with the help of hadess. Now all we need is a new rpm version with support for this, and then for rpm based distros (e.g. Fedora) it should just work. For Ubuntu the data is already present in the ton of desktop files that are shipped in gnome-app-install – and I’m sure it will be easy to get at this data in the apt2 backend. Other distros will have to work out how to do this, although I’m sure one of the existing methods will be easy to adapt.

So, enough of the geeky. What do you all think of this:

Code about to hit master…

Comments?