[bug#73769] [PATCH] automake: distribute local gnulib directory modules

Michael Pratt wrote:
> I believe many of you have read this already.
> 
> https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00124.html
> ...
> So hopefully we all agree that in general this should be done,

No, not everyone agrees with Simon's "de-vendoring". In particular, I disagree
with the "Pre-generated files (e.g., ./configure) should be re-generated" part,
because it invalidates the pre-release testing done on the tarball.

> even with a release tarball one should be capable of regenerating every build step
> that a maintainer would do.

I agree with that: A user or distributor should be able to pull a tarball,
apply a patch, and re-run gnulib-tool. The need to pull some other git repos
at this point is a problem though. Cf.
https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00239.html

> I have a v2 patch ready if the following arguments make enough sense...
> or perhaps sending a patch to gnulib would be better?

I'm glad that you are realizing the big mistake you were doing: Based on
discussions (only discussions, not even a committed patch!) with 1 single
package that uses gnulib, you wanted to modify the way gnulib works for
*everyone*. And that without even CCing the gnulib people!!

Really the way to do such a thing in a socially acceptable way is to
  1. discuss with 1 package,
  2. get a patch committed for that 1 package,
  3. get in touch with the gnulib people to see whether it generalizes
     maybe to _some_ other packages,
  4. only if it turns out that it generalizes to _all_ packages, come to
     Automake and ask for an Automake change.

Bruno