[debhelper-devel] Bug#895061: exclusions and dh_missing

[Nicolas Boulenguez]

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.