bug#22070: Recreating release 1.6 from git

[Eric Blake]

On 12/01/2015 04:00 PM, Doug Evans wrote:
> Ok, last question and then you can close this.
> 
> I'm trying to verify the correct version of gnulib is being used,
> but I can't see anything in the bootstrap script that
> guarantees this. E.g., I expected to find a gnulib commit id
> or tag or some such that specified the version of gnulib that
> was used when the original 1.6 release was made.
> Do you know how this is done?

Via git submodules.  The git history of the gnulib submodule shows which
version of gnulib.git was tied to a particular commit in gzip.git.
Updating to a newer gnulib commit is a conscious decision done by the
maintainer, and shows up in the gzip git history (that is, we are NOT
automatically tracking the latest gnulib.git, which also means that we
do not have to worry about the latest gnulib changes causing regressions
in gzip until we are ready to do a conscious submodule bump).  For
example, commit 34f80f4a was the most recent modification at the time of
my email, where we bumped from gnulib commit 9be0b54 to 5028090.

Sadly, 'git show v1.6:gnulib' complains 'fatal: bad object v1.6:gnulib',
at least for git 2.4.3.  You're welcome to propose a patch to upstream
git.git that would teach 'git show' how to show submodule commit ids
automatically, instead of choking.  I had to use 'git log -p v1.6
gnulib' to learn that v1.6 was made with gnulib.git commit 9be0b54.

The bootstrap script calls 'git submodule update' to forcefully update
the gnulib submodule to the correct release point, before calling the
embedded gnulib-tool to copy the appropriate files from that point in
time of the submodule into the gzip working tree.

The use of git submodules in projects that are gnulib clients is
actually desirable; because it would not scale to add lots of client
labels directly into upstream gnulib.git for every client project's
release.  So you have to read the history of the client, and not of
gnulib itself, to learn which version of gnulib a client depended on at
a given time.

[Oh, and top-posting on technical lists gets difficult to read]

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature