FOSDEM 2008

So another year, another great FOSDEM. On Sunday I presented an introduction to PackageKit. The slides are now online for any that missed it.

For those of you I met, it was great to see you. I was really worried I didn't get a chance to say hi to some key people, so if I didn't grab you and say thanks then I apologize, and I hope to shake your hand soon.

Big changes

Today I resigned from my graduate hardware engineer position at BAE Systems. In a little over one months time I will be starting at Red Hat UK, with Jonathan Blandford as my boss. I'll primarily be working on laptop support issues, but with a bit of time spent on PackageKit and other cool stuff. This is a great opportunity for me, and I'm really looking forward to solving new problems. Good news.

Service Packs and PackageKit

Microsoft Windows has the concept of service packs, i.e. a large package containing all the fixes to date. Service packs are really useful if a computer only has no (or slow) network connectivity and the whole system has to be updated on multiple computers.

I think some sort of PackageKit integration with a “service pack” type DVD/CD would be useful. Note, this concept is totally different to one click install, as it has a different perspective.

I think the ideal use case is this:

  • [1] insert CD/DVD/PenDrive with service pack .debs and .rpms on
  • [2a] cdrom is autorun by gnome-volume-manager and the location passed to gnome-packagekit to initiate a service pack update
  • [2b] gnome-packagekit watches for a cdrom to be inserted
  • [2c] packagekitd watches for a cdrom to be inserted and triggers a client side signal (means client doesn't have dep on libhal, and the daemon can Lock() the cd device from ejecting when the transaction starts)
  • [2d] gvfs does a new-fangled thing for autolaunch and tells gnome-packagekit
  • [3] gnome-packagekit asks the user to confirm it's valid update media, asks for PolicyKit auth and runs the ServicePack() backend method on the media device.

For [2] we'll need an identifier that can be recognized by PackageKit, maybe just the presence of the file packagekit-autostart.ini on the CDROM or DVD. The format of this file can be trivial, something like:

[PackageKit Autostart Section]
DataLocation=Fedora/updates/rpm
DistroName=Fedora8

For [3] we can make the ServicePack() method just do something like “yum local update /media/DiscFoo/Fedora/updates/rpm/*.rpm” (backend specific, and within yumBackend obviously).

Michael Vogt has already worked on add-on cds for Ubuntu, and I think there's some momentum for this for Fedora also. I really think this could rock.  I'm also after a better name than ServicePack, maybe UpdateMedia or UpdatePack might be better choices.

Comments?

Cool localisation stuff happening with PackageKit

Package spec files and PackageKit backends are rarely localised. This doesn't matter much if you speak English, but really sucks if you don't. We can't fix all the distro tools and all the packages in the world, but we can do our best to be clever:

This is with my locale set to “en_GB” and the libpackagekit results hardcoded to “fr” – the two will match up eventually of course.

Theres a new GObject called PkExtra in libpackagekit that lets you query (as a user) a small cached sqlite repository containing all the localisations and icon names. The data from this is populated per system (as root) from a few information sources:

  • All the installed desktop files in /usr/share/applications (this works now)
  • Metadata from the online desktop project (to get things like popularity, WIP)
  • Information about non-installed packages generated from the distro builder (WIP)

I don't think caching the installed icons and shipping them seporatly is a good idea, just from a size point of view.

The sqlite database is currently at 200kb in size with 201 applications installed (i.e. things that ship desktop files) so I'm guessing it would be couple of Mb with the entire fedora repository of information in and the online desktop stuff. Of course, being sqlite, it's very quick to query.

Updating the offline repo would be left to the distro packager, as of course, this stuff is all per-distribution. There is lots of stuff still to work out, but slowly, it's coming together. Comments welcome.