This is a followup to the earlier design of dh. After converting many packages to minimal rules files using dh, I find that it works very well for the 3 line rules file case, which works for 80% of packages. But getting from there to a slightly more complex rules file that 20% of packages need can be non-obvious.

So, let's make it obvious.

Suppose I want to run dh_compress -Xsomefile. But my rules file as it currently stands doesn't offer an easy place to run that command:

#!/usr/bin/make -f
%:
    dh $@

To use dh in this situation you had to go look up rather a lot of boilerplate, and to insert an explicit version of the right target, with the right dependencies, that called dh before and after your command:

#!/usr/bin/make -f
%:
    dh $@

binary: binary-indep
binary-indep:
    dh $@ --before dh_compress
    dh_compress -Xsomefile
    dh $@ --after dh_compress

That took me half an hour to come up with, and I wrote this stuff! Also, if I want to override a second command, I have to do it in the right order. So, the full flexability of debhelper is there, but it's too hard to get at.

Here's the new new thing.

#!/usr/bin/make -f
%:
    dh $@

override_dh_compress:
        dh_compress -Xsomefile

What this does should be obvious. These override targets can be written for any debhelper command that you need to change the default behavior of, or even avoid running at all.

override_dh_auto_configure:
    ./configure --with-kitchen-sink

override_dh_auto_test:
    # The test suite for this package is busted on s390.
    if [ $DEB_BUILD_ARCH != s390 ]; then dh_auto_test; fi

The overrides can also be used to run additional stuff before, or after any debhelper command:

override_dh_clean:
    dh_clean
    rm -rf build_dir

So, I think that's beautiful. Simple, clean, no boilerplate, and intuitively obvious if you are familiar with debhelper.

FWIW, the implementation, which will be in the next debhelper release unless someone screams loudly, is not beautiful. Mostly because I sorta shot myself in the foot with the cute implicit "%:" rules. But, I got around it. :-)