Nicolas Boulenguez:
> My understanding (so far) is that there are three unselection
> mechanisms, and I have the feeling that only one is worth supporting.
>
Ok, just to confirm, I understood you correct, those three are:
1) --exclude for paths debhelper automatically work on (but not
--ignore)
2) --exclude for paths provided by the maintainer either via arguments
or config file.
3) --ignore
And 1) is the only one you want to preserve?
>
> [...]
>
> 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
>
I know of two common use-cases here for --exclude. If we can find an
alternative for those, I am happy to consider deprecating --exclude for
these purposes.
1) Ignore files/paths from the config file that are conditionally
built. This is usually observed via the following pattern:
IGNORE_FOO :=
ifeq ...
IGNORE_FOO := -X foo
endif
[...]
dh_install $(IGNORE_FOO)
2) The case you described above where people want "all the files in
foo except bar".
You later mention the executable config files as a possible solution. I
disagree that executable config files /in their current form/ is ready
to replace these patterns.
That said, I know dh-exec is doing a good job at making executable
config files easier to work with. It is sadly missing someone with
interest and motivation to maintain it and I have been hoping someone
picked it up (I do not have a vision for dh-exec, so I am not the right
one to pick it up).
Note that I am very happy to work with you (or anyone else) on improving
dh-exec and the debhelper <=> dh-exec integration. If the changes are
useful and stable, we can look at merging some of them back eventually
(dh-exec has a much better interface for prototyping, while debhelper
effectively commits to 10-12 years of support the moment it is released
in a compat level).
> [...]
>
> 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.
>
While I loath the fact that --exclude makes things hard to optimize, I
am not entirely convinced the overhead of using --exclude is an issue in
itself at the moment.
Performance-wise, I suspect #866581 is a much lower hanging fruit. Or
the fact that Dh_Lib takes 0.035s to load costing us 100ms per 3
debhelper command run during build on pure "do the same initialization
over and over again".
> It forces debhelper to contain code that is hard to write, maintain
> and test.
I admit that most --exclude is hard to test. The notable exception
being "excludefile", which is rather easy to test (compared to things in
debhelper in general).
> 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 ?
>
EXCLUDE_FIND will correctly be passed to find, but every thing else is
indeed a hassle to quote correctly. Related annoyances: #864182
I would indeed prefer less need for "complex_doit".
> [...]
>
> To some extent, the same concern applies to --ignore.
> [...]
> 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.
>
I was going argue that it was not worth the removal. But there is only
one or two consumers (left?) of --ignore according to codesearch[1].
Even cdbs does not appear to use it at all.
If you can convince the remaining consumers of --ignore to migrate
away, then I am happy to drop the option when we release debhelper 12.
Thanks,
~Niels
[1] https://codesearch.debian.net/search?q=dh.*.%5Cs--ignore
E.g. gutenprint
