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

 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

        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.



E.g. gutenprint

Reply via email to