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)
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
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.
 Slight oversimplification; two scripts cram the 3-line form in one line for no good reason and are counted as 3-lines above.