Lars wonders about debhelper's approach of inserting script fragments into package maintainer scripts.

It's really very interesting to survey debhelper's collection of fragments, in its autoscripts directory. Of the 55 fragments, the mean length is 4.5 lines, and the mode (and also shortest[1]) length is 3 lines.

The 32 scripts that are each three lines follow a very simple pattern:

if [ "$1" = something ] && exists some-script; then
    some-script some-parameters
fi

It would be nice to get that down to Lar's more declarative one line approach:

some-script some-parameters $@

In practice though, many of these scripts are not always available, and so the postinst has to test for them before running them. And making them test the postinst's parameters to see if they should do anything makes them less general and less flexible (ie, not able to be run easily by a sysadmin), and so keeping the "$1" test in the postinst is reasonable.

So, I think I've done a pretty good job at keeping debhelper script fragments short and keeping most of the possibly buggy bits that might need maintenace out of debhelper. The exceptions tend to be either older scripts, from a time when I was less careful about doing do, and fragments of code that I could not pawn off onto some other package, often because there was no package that owned the issue. (The dh_usrlocal code is the best example of that.)

The most promising way to improve things seems to be using dpkg triggers, which is why I was very enthuisiastic when we finally got them, over a year ago. Triggers let many of these hooks into maintainer scripts go away completely. Rather than each package having to test for and call update-menus, menu can simply trigger on the modification of any menu file. Once menu finishes the conversion to using triggers, debhelper can drop those fragments entirely.

Triggers seem likely to be able to eliminate well over 90% of the things we need to put into maintainer scripts, and I hope at least half of debhelper's script fragments can eventually go away thanks to them. The others seem more difficult.

You probably cannot, for example, make a trigger that does something sane when an init script is installed. Debhelper has at least three different fragements that it can put into postinst scripts to handle init scripts, and these only cover the most common three cases (start, don't start, don't restart on upgrade).

Moving even these things into a declarative form has long been a dream of mine. Maybe it could be done with a control file that specifies which of the methods for running the package's init script to use for this package.

But it seems we can't do away with maintainer scripts entirely, no matter how hard we try. That's because maintainer scripts are our only way to deal with other crippling bugs in old versions of a package, and with upgrade issues, and with all the other myriad things that we put custom code in them to deal with. Pity.

[1] Slight oversimplification; two scripts cram the 3-line form in one line for no good reason and are counted as 3-lines above.

Things are feeling unstable around here. That's mostly a good thing, but ...

Switching to ext4 seemed like a good idea since I was resizing my file server's filesystem anyway. And I'd used ext4 on my laptop for a while, with no problems. But, I ran into a bug that causes ext4 to hang. So I'm left with my main server at home piling up hundreds of processes in uninterruptible sleep when this breaks. And, eventually running out of memory and dying.

There's a fix, in newer -pre kernels, but so far I have not had luck getting those kernels to work with my Thecus. There's a regression in those kernels that breaks the NIC, and my attempt at backing that changeset out still left it unable to get on the net. Did I mention that I don't even have a serial console on this machine? That natively building a kernel on armel takes about 12 hours? Makes this sort of thing much fun. Need to find the right header and spend some time with a soldering iron one day.

Converting back to ext3 would mean resizing a 2 TB array, which ran resize2fs out of memory when I tried it. It looks like I will have to leave /home unmounted while I'm on my trip, to keep the rest of the server up. When I get back, I've ordered a third terabyte drive, and will use it to switch back to ext3. Having these silly amounts of storage is fun, until you have to admin it.

The other fun I've run into is that a new version of mpd has horrible performance on arm. Max Kellermann was very helpful in tracking down the issues involved, and helping me get a version that has at least reasonable performance again.

Oh, and if someone could tell me why gnome terminal 2.24.3 can't open links anymore, I'd appreaciate it.

I wish that gnome-terminal was able to support multi-line URLs, or that mutt was able to render long urls on a single logical line.

If you use mutt in gnome-terminal, you may have noticed that urls that wrap to another line cannot be opened using gnome-terminal's context menu. Of course, resizing the terminal to be wide enough works around the problem, but is not always practical.

Another workaround is to pipe the message to less. While the url will still be displayed split across multiple lines, gnome-terminal will then recognize the whole url as one thing.

Why does less work where mutt fails? Well, it seems that mutt and less print the url differently. less simply prints the whole url, and lets gnome-terminal wrap it to the next line. mutt prints the first line of the url, then moves the cursor to the start of the next line, and prints the remainder.

This could be fixed either by making gnome-terminal smarter about finding the end of urls that are sent to it in multiple pieces, or by making mutt (or likely really ncurses) change how it outputs long lines.