Year: 2008

Software Log Viewer

PackageKit has always had a log viewer, but I would be the first to admit that it looked shite, and wasn’t really useful for anybody.

I’ve spent a couple of hours, adding more columns and adding a filter facility so that you can narrow down the results to something useful.


Use cases for this tool:

  • Something in yesterdays automatic update broke firefox. What was updated?
  • Did I update firefox last week?
  • (for backends that support rollback) Take me to the snapshot before I installed XFCE

Comments welcome.

Service Pack GUI?

As part of GSoC 2008, Shishir Goel added Service Pack functionality to PackageKit. To explain what a service pack is, it’s best to show a few use-cases.

  1. You have seven desktops you’ve just installed with Fedora 9. Each one needs to have 204Mb of updates installed.
  2. You have a laptop that needs network drivers before it can download updates, and you have a similar up to date laptop with internet access nearby. The network drivers require a ton of dependencies, and other packages to be upgraded before they will install.
  3. You frequently install Linux on other peoples computers. You carry around a live-cd and a pendrive with a single 204Mb file “Fedora-updates-SP1.servicepack” which contains all the updates since last week.

Now, you may or may not know, that you have been able to install .servicepack files since PackageKit 0.3.2 — but creating them has always been tricky. Yesterday I spent a few hours rewriting some of the client code, and making the pkgenpack command line options more sane.

The pkgenpack is a command line tool for creating service pack files. You can find out more information about how it works by reading the man page.
Yes, I know the man page formatting sucks, suggestions on how to fix (and patches!) welcome.

Internally, the pack file is just an uncompressed tarball, with the packages and a single metadata.conf file inside. The metadata file is just the distro_id (name, version, arch, etc) and the time of creation. This ensures you don’t try installing a fedora-9-i386 service pack on a ubuntu-intrepid-ppc machine. In this case you also get a nice error message telling you what you did wrong.

Now, command line tools are all the rage these days, but what about a GUI? I mocked this up in glade yesterday, and wouldn’t take too long to turn into an actual program.

Comments?

PackageKit self checks

PackageKit is quite a complicated code base. As with all my projects, there is a substantial self check framework that’s designed to catch bugs and regressions before we push releases. This was something enforced by my previous employer, but I’m sure it’s a good idea for any non-trivial code base, and it’s something I’ll continue to do.

Self check example
Self check example

The number of tests currently:

daemon: 216
libpackagekit: 202
gnome-packagekit: 75

The tests are all injecting valid and invalid input and then testing if the code does the right thing. This works really well for the daemon and the library, but does not work well for the GUI applications that need a full GUI framework.

I’ve tried dogtail, but I’m finding it hard to use, and really wanted something I could integrate with my existing system in C. Do any of you hackers recommend anything in particular or should I persist with dogtail? So far it’s looking best of the bunch.

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.

Fedora Forums

I’ve just been banned on the Fedora Forums.

I’ve been asking users with PackageKit bugs to report them upstream on the mailing list or in bugzilla, explaining what common error messages mean, and how to fix other problems.
This, it turns out isn’t what the forums are for. I guess it’s just for uniformed users telling less informed users how to “fix” things. My mistake.

I won’t be even reading the forums anymore, and consider the couple of hours I spent on the forums answering questions and educating users about PackageKit wasted.
These are all the posts I’ve made on the forum if you want to check any of my messages. A few of them are pretty blunt, but the personal critique of my skills as a programmer and PackageKit is pretty blunt too (especially by a “Community Manager“).

Advice to developers: Don’t bother.