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
