My understanding (so far) is that there are three unselection
mechanisms, and I have the feeling that only one is worth supporting.
It is useful to provide at least a sensible way to overrides hardcoded
or autodetected paths.
override_dh_link:
dh_link --exclude=/non/standard/symlink
override_dh_compress:
dh_compress --exclude=/non/standard/format
The --exclude option has a second, distinct, and arguable usage:
to extend the expressivity of glob patterns, like in:
override_dh_installexamples:
dh_installexamples --exclude=foo/bar foo
It allows the caller to express two contradictory wishes, leading
debhelper to guess the actual intention (should dh_missing complain?).
It mixes two kinds of matching patterns in an inconsistent interface.
* dh_installexamples 'foo*' --exclude=foo
seems to install foobar but does not.
* dh_installexamples foo --exclude=foo/bar
seems to install foo/foo/bar but does not.
Good documentation is only a work-around.
For more fun, the incompatible wishes may be in different locations:
'foo*' in debian/examples and '--exclude=foo' in debian/rules.
It forces debhelper to be less performant, as each existing path must
be matched against two distinct kinds of patterns in the end.
Also, --exclude prevents a simple 'chmod -a' for directories.
It forces debhelper to contain code that is hard to write, maintain
and test. Factorization like EXCLUDE_FIND is only a work-around, it
does not change that a Perl script generates a Shell command
describing a find request compiling regular expressions translated
from command-line arguments usually transmited by a Shell launched by
Make. Who would bet that all special characters are handled correctly
in all corner cases ?
Now consider that all this can be replaced with an explicit debian/examples
foo/baz
foobar
or if the list keeps varying by an executable debian/examples with
#!/bin/sh
find foo -mindepth 1 -maxdepth 1 -not -name bar
(and of course foo/bar in debian/not-installed).
To some extent, the same concern applies to --ignore.
override_dh_foo:
dh_foo --package=pkg --ignore=debian/pkg.cfg
dh_foo --remaining-packages
The now common source format 3.0 has made the original motivation
obsolete (if upstream tarball contains a debian/ subdirectory, it is
not extracted by dpkg-source at all).
If necessary, the maintainer can remove debian/pkg.cfg, rename it, or
add it to debian/clean.
Is it worth to slow down each call to pkgfile() to handle this?
However, the performance and complexity costs are way smaller, so the
balance with the burden of removing an option is probably different.
