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.