Wandering Thoughts archives

How not to improve your package updater application

Earlier today I tweeted:

Every time I use the Fedora 16 gpk-update-viewer I'm filled with anger for what someone did to a nice, usable program.

Now I feel like explaining that (in the spirit of an earlier entry). First, gpk-update-viewer is the program behind the 'Software Update' information display on Fedora systems; it's part of PackageKit.

In Fedora 15, the (Gnome) interface for it has two relatively minor issues (which you can actually see in the current screenshots on the PackageKit website): it doesn't group the updates into separate sections for security updates, bugfix updates, and regular updates, and it always shows the 'Details' area even if you're not interested in it. In the Fedora 16 version, someone decided to fix these problems. To properly appreciate the result, I must show you a picture (which I am not going to inline here because it's too big): a screenshot of the Fedora 16 gpk-update-viewer.

The Fedora 16 version has certainly fixed those two little problems; the Details area can now be folded away, and updates are now grouped. However this 'improvement' has created all of the following issues, many of them disastrous:

• the 'Details' area for the details of the updates is not resizable; it's fixed at four and a bit lines, which is completely and utterly inadequate for usefully reading those details without endless scrolling. I am now very glad that I recently contrived a scroll wheel.
• if you scroll the 'Details' area (and you will be) and then move to another package, the area's scroll position is not reset to the top. It doesn't always stay static either; at least sometimes it shifts oddly.

Since the entire reason I'm running gpk-update-viewer at all is to read the update details, this change alone is a huge usability loss. (I check for and actually apply updates through yum, but as far as I know g-u-v is the only tool for seeing the update text (which is not the same as the RPM changelogs).)

• there is no longer any indication of if the update will require a system reboot or for you to log out and back in again. Fedora 15 annotated such updates with little icons.

• Fedora 15 mostly grouped all related binary packages together as a single entry (which you could expand to see the list of individual packages that would be updated). Fedora 16 lists every binary package separately, even in cases where an update to a single source package produces a shower of fifteen or twenty updated binary packages.

  (You can see this in the screenshot; in Fedora 15, there would not be separate entries for 'cheese' and 'cheese-libs'. Fedora 15's version of this was incomplete, but it was still much better than not having this at all.)

• Those headings for the type of updates you see in the screenshot ('Security updates' and 'Bug fix updates') are actually selectable entries. You can click on them and, more importantly, if you are scrolling through the list of updates you will wind up on those headings too (and have to explicitly scroll past them). This is especially irritating while you are using the arrow keys to scroll to the next entry because your mouse cursor is in the Details area so you can use your scroll wheel to read the update details.

And on a slightly more minor gripe, the Fedora 16 version always starts up with a completely crazy window size when I run it under fvwm in my normal configuration. No other Gnome program seems to have this problem and the Fedora 15 version was (and is) fine.

(Fedora 15 has gnome-packagekit 3.0.0; Fedora 16 has 3.2.1. Sadly the Fedora 15 binary doesn't work on Fedora 16, but maybe I can recompile the old version from source.)

What debugging info I want from things like SMF and systemd

I've recently been tooling around in both SMF and systemd, so I've developed some strong opinions on what startup systems like this need to provide to help working sysadmins. It will probably not surprise you to know that neither SMF nor systemd deliver entirely useful information today.

There are two sorts of service startup problems, which I'll call the simple and the complex. The simple question is 'why did this service fail to start'. To answer this sysadmins need to know exactly what was run and what happened to it, ideally including its output and log messages; if the service wasn't started because of missing dependencies, we need to know what they were. SMF and systemd both half-heartedly deliver this today.

(Neither has output that is optimized for making it clear if a service is not enabled at all, is enabled but had missing dependencies, or if it was enabled and failed to start or died later. In fact distinguishing between 'failed to start' and 'seemed to start fine, died later' is actually fairly important but doesn't tend to be reported well.)

The complex startup problems are ordering problems, such as our recent issues with ZFS pool activation and iSCSI disk discovery. To deal with these issues, you need two things: you need to know the actual order that service startup both started and finished in (you need both because in a modern system several services may be starting at once), and you need to know why, ie the service dependency graph. In fact you want several views of the service dependency graph, for example the transitive expansion of dependencies both ways for some service: 'everything that has to be up for this service to start' and 'everything that requires this service to be up'. It's also handy to be able to ask questions like 'does service X depend on service Y in some way, and if so how?'

This is mostly missing in SMF and systemd today, as far as I can see. It's possible that systemd can be coaxed into giving you the information, but if so how to do it has been carefully hidden from harried sysadmins.

(As an example of getting it incomplete, SMF will give you direct dependencies in both ways but not indirect ones, which leads to a frustrating game of 'chase the dependency'.)