Technical Blog of Richard Hughes

Some people may have noticed that there was a flurry of activity for PackageKit in the last few weeks, and then nothing for a whole week. The reason is that I've finished my internment at Red Hat and now am on a graduate program for a large defence company. This is not the end of my OSS activity, so panic not. Working for Red Hat was great, and I would recommend it to anyone interested in working with the best open source company out there. This week was my first week at my new job, and rather hectic; so if I haven't answered your email I'll catch up with it on the weekend. So PackageKit. This week I've been moving around blobs of code and refactoring stuff, removing bodges and adding self check code in the daemon. It's not particularly interesting to blog about as it's not screenshottable. The daemon is a whole lot more sane now, and the API has improved lots in my opinion. There's still some more API additions we need to make (to get the update details for a particular package_id comes to mind..) but generally I think we are nearly there. I'm going to be working on more documentation for backend writers as what I've got now is a little hard to read. Backends are now compiled .so objects with optional external helpers. This removed the horrific gobject hacks I was using before, and actually makes a nice abstraction. It should be a lot easier for new backend writers to add a new backend into the tree, and makes it easier to test as you can now select the test or dummy backends at runtime rather than having to recompile. The yum backend is nearly complete, apt is about half done, conary similar, and a preliminary box backend has also been added. There's interest in adding pacman, zypp and emerge backends also. I want to apologise a little to the backend writers. I know I keep tweaking the API, moving files about, and changing the enum defines but I believe doing this early in the project will give us a complete system that is free from bodges around premature design decisions. I need to change a few enumerated types in the next couple of days, add the internal queuing API and add a whole heap more self tests and then I probably should release 0.1.0 to the unsuspecting public. Talking of which. I know self tests are not the most interesting bits of code, but they are pretty easy to add. If you are not a great C coder, but want to get your hands dirty with PackageKit you could help me write the simple tests. Most are of the type: /* check function does not explode with NULL */ ret=function(NULL); if (!ret) abort(); /* check return type*/ ret=function2(“dave”); if (ret != ENUM_DAVE) abort(); If you look the existing tests you'll see the sort of things we test for and the simple framework that we are using to make the tests a bit easier to write. Email me and I can tell you what needs to be done. Thanks.

People are odd creatures. Sometimes people want to see why different packages need to be updated and want more information about what the update will achieve.

The pk-updates application will list updates and show more information if you click on an entry. There is no such information from yum yet (AFAICT), but I'm trying to design the signal to be powerful enough for the other backends and for yum when it gets that data.

If you click close, the application will close. If you click apply, then the application will close, and the update will continue in the background. Yay for async.

If anyone wants to fix any of the applications to match the GNOME HIG (or other spelling or grammar fixes), send me an email and I'll get you commit on my internal development server; I'm really no good at that sort of stuff. Thanks.

Lazyweb: is it possible to put a GtkButton in a GtkTreeView? If yes, pointers to example code welcome. Thanks.

When pk-application gets packages that meet a search criteria it just prints the package name, version, summary and if it's installed or not. This is really bad from a UI point of view.

What I want is:

__________
[        ]  packagename-version
[  ICON  ]  Translated short description
[________]     [more]

Unfortunately, neither the translated short description nor the icon is present in a rpm or deb. This seems odd to me, as in Windows world an installer package gets to choose its own icon, although I appreciate there is usually a loader involved.

gnome-app-install hardcodes everything to ubuntu package naming and iterates on a mirror of the ubuntu servers picking out desktop files. This isn't ideal as it's ubuntu specific and requires quite a bit of manual fixing up and package specific checks. But it looks good.

So we have several solutions to this problem:

1. Modify every packaging system to return a translated package name and icon for each package in the repo.
2. Maintain a separate packagekit-data package which is just full of icon files and translated .desktop files, and a per-distro common_name->package_name database.
3. Don't display an icon for the package and only show the icon of the group type.

Option 1 would require massive code changes in all the packaging formats and isn't really an option.
Option 2 is a never-ending-story and there would be a massive workload to keep the database up to date and the translations fresh. There would need to be some sort of web interface to keep everything updated without a deluge of patches.
Option 3 is what I'm doing now, but looks completely amateur compared to gnome-app-install.

So, ideas?

Progress with PackageKit is amazing. I've had lots and lots of patches from many contributors which is great, thanks to you all. There is still lots of library and API churn but the code and GUIs are being slowly developed into something useful. The yum backend is almost complete.

There's now a mailing list for PackageKit development. Please subscribe if you want notifications of new features, or if you have questions about the GUI or daemon, or if you are a backend writer. It's hopefully going to be a low-traffic list.

Also, the download location of the daemon is now:

git clone git://anongit.freedesktop.org/git/packagekit

Thanks to the fd.o admin for sorting out my project creation request.

edit: use the fd.o mailing list, not the google group. Thanks.

Anyone interested in PackageKit develpment is invited to join the channel #PackageKit on freenode.
We can answer questions on backends, GUI's or anything else PackageKit related.

The PackageKit source tree needed gtk, libnotify and all sorts of weird gnomey libs to compile, which seemed to upset the non-GNOME people a little. The actual daemon just needs glib, libnm, dbus-glib and policykit so it did seem somewhat non-optimal to me as well. I've split the daemon and GUI parts into two projects:

 git clone git://people.freedesktop.org/~hughsient/PackageKit git clone git://people.freedesktop.org/~hughsient/gnome-packagekit 

Just install gnome-packagekit when you have PackageKit installed – gnome-packagekit uses libpackagekit to do all the heavy lifting, so the GUI bits are actually very simple:

 [hughsie@hughsie-laptop src]$ wc -l *.c *.h    56 pk-application.h   725 pk-application.c   104 pk-application-main.c    60 pk-notify.h   958 pk-notify.c   76 pk-update-icon.c   1979 total 

In the gnome-packagekit project I'll start marking strings translatable, and there's also a yelp file for someone to fill out for me in the future. I might move gnome-packagekit to GNOME svn when things are a bit more stable, so stuff like translations and HIG changes are easy to commit. This means it's really trivial to port an existing applications to use libpackagekit, or to create, for example, kpackagekit.

Okay, quite a major omission on my part, but the PackageKit 'Package' signal previously didn't send the version or architecture of the queried package. It does now.

I've also merged in the start of a conary backend (thanks Ken!) and made the spawn code an order of magnitude faster. There's also quite a bit of interest in making a pacman and emerge backend for PackageKit too.

This morning I've added the RequireRestart signal into PackageKit, and connected it up with the server and client. All code is in git master.

The restart types are system (reboot), session (logout and back in) and application (restart program).
Only the dummy backend supports this for now, although it's trivial to add to the others.

Request for yum help:

Do you know python? Are you familiar with rpm and yum internals? if so please email me – the yum backend needs some serious love. I've got a few people helping with PackageKit the moment; Tom Parker is rocking with the libapt-pkg backend and skvidal and Luke Macken are helping with the yum backend but I need more people to write new backend code.

Request for backend writers:

Want to join the fun? The core code and API are ready, any there is even a README for you to follow. I would like to see urpmi and conary backends added next week if possible. All it takes is someone very familiar with the packaging system and a few hours of time. If you supply me with scripts that adhere to the common helper standard then I'll even wire up PackageKit for you.

Thanks.

PackageKit has an application called pk-update-icon that is run once per session automatically. It is a lightweight binary that just calls into PackageKit and watches for status changes. It initiates the Refresh (non-forced) and GetUpdates after login and periodically checks for updates every couple of hours. This isn't configurable, but it would be trivial to hook up to gconf.

It has two status area icons, one for PackageKit current status and one for updates. Hold the pitchforks.

The PackageKit status icon only appears when a job is in progress, for instance a cog icon appears when doing an rpm install. It disappears when PackageKit is shutdown, which is currently after 60 seconds idle. It's basically a way of seeing what PackageKit is currently doing.

The update icon only appears when there are updates available, and additionally a libnotify window appears if there are critical updates available. Below is the dummy backend displaying the data, as yum doesn't seem to know if an update is security sensitive or normal. Ideas welcome on how to fix this.

Code is in git. My English spelling and grammar are crap (as usual), and nothing is localized, but that can be fixed later. Or alternatively, I accept patches.