Re: Please include the local gnulib modules in releases

[Michael Pratt]

Hi Pádraig,

On Monday, October 7th, 2024 at 07:03, Pádraig Brady <P@draigBrady.com> wrote:

> Well maybe, but then we'd have two copies of these files in the release 
> tarball.

While compression would help in this case, it's really not necessary to have 
extra copies
of the source itself. What's needed is just the "modules" files which are 
missing,
then someone who "knows what they're doing" can put the pieces together and do 
a quick copy
before running the script.

The fact of the files being split up can also be mentioned in one of the 
READMEs,
even if that README isn't included in release.

Even better, at some point the bootstrap script can be edited in order to 
identify
that the sources that would be copied over to the "lib" subdirectory are 
already there,
and not complain if the --force option is given, or handle the copy-back before 
autoreconf.

> Given the bootstrap is really only applicable from a dev checkout,
> and gnulib needs to be accessed separately anyway,
> would it make more sense to access the coreutils git repos directly?
> I.e. using git, or if you needed tarballs sync'd to a release point
> accessing initially from https://github.com/coreutils/coreutils/tags for e.g.

The checksum of the tarball release is used to guarantee the reproducibility of 
the build,
there's also a slight performance difference... so while we can it's best not 
to...
Having a full copy of source in a release tarball is ideal.
We already have gnulib as part of the build, for version control whenever 
bootstrap/autoreconf is necessary.

--
Thanks for considering,
MCP