Re: git-version-gen not working with Savannah/cgit snapshots

[Bruno Haible]

Hi Branden,

Have things worked out for you by now? Is the .tarball-version workflow
clear? Should we document it better in the git-version-gen script?

Bruno

===========================================================================
I wrote:
> > > By the way, if submodules are not what you want, i.e. if you always
> > > want to use the newest gnulib, I suggest to use the
> > > gnulib/top/gitsub.sh script.
> > 
> > I have no principled objection to submodules; the decision to use them
> > (well, just this one, for gnulib) was taken before I joined groff
> > development.
> 
> OK, let's stick to that, then. Submodules.
> 
> > configure.ac says this.
> > 
> > AC_INIT([GNU roff],
> >         m4_esyscmd([build-aux/git-version-gen --fallback 1.23.0.rc1 \
> >           --prefix "" .tarball-version]),
> >         http://savannah.gnu.org/bugs/?group=groff,
> >         [groff])
> 
> Ah, you want to use git-version-gen to infer the version of groff, not
> the version of gnulib! This means that we have two independent topics,
> then:
>   (I) git-version-gen and configure.ac
>   (II) bootstrap and wget vs. 'git submodule'.
> From your original mail I got the impression that those were related,
> leading to confusing discussions.
> 
> ====================================
> (I) git-version-gen and configure.ac
> ====================================
> 
> Many packages (autoconf, bison, coreutils, diffutils, gettext, guix, gzip,
> libidn, libtool, m4, patch, wget, ...) use the following in their 
> configure.ac:
> 
>   m4_esyscmd([build-aux/git-version-gen .tarball-version])
> 
> Groff uses --prefix "", since its 'git tags' list doesn't have a prefix,
> and it uses option '--fallback 1.23.0.rc1'.
> Now, let's look at the outcome, depending on each of the 4 cases:
> 
>   - .git directory present, git program present:
>      coreutils: 9.1.25-93e099e
>      groff:     1.23.0.rc1.2532-73999
> 
>   - .git directory present, git program absent:
>      coreutils: UNKNOWN
>      groff:     1.23.0.rc1
> 
>   - .git directory removed, git program present:
>      coreutils: UNKNOWN
>      groff:     UNKNOWN
> 
>   - .git directory removed, git program absent:
>      coreutils: UNKNOWN
>      groff:     1.23.0.rc1
> 
> The effect of your patch is to use the fallback value in the 3rd case too.
> 
> But the use-case of the 3rd and 4th case is when the user has unpacked a
> tarball. But the tarball is supposed to contain a file '.tarball-version';
> *that* is where the fallback is supposed to come from.
> 
> So, to me it appears that groff should package a file '.tarball-version'
> in the tarballs, like the mentioned GNU packages do; then
>   - your git-version-gen invocation in configure.ac snippet would work,
>   - you would not need the --fallback option,
>   - and thus you would not need to modify the configure.ac (which is
>     tracked in version control) each time you make a prerelease.
> 
> I agree that the workflow with .tarball-version is not well documented;
> here's how I use it in GNU gettext: [1].
> 
> But if you want to have another workflow, where you put the version into
> configure.ac instead of .tarball-version, then
>   1) You need to explain what the advantages are compared to the other
>      workflow (since it costs time to maintain two different approaches
>      for the same objective),
>   2) four changes are needed in build-aux/git-version-gen:
>      - your patch to the 'elif' line,
>      - a modification to the help text for --fallback,
>      - making the '.tarball-version' argument optional instead of mandatory,
>      - comment changes that indicate how to use your alternate workflow.
> 
> =======================
> (II) bootstrap and wget
> =======================
> 
> > >   - You have submodule information in the parent git repository (groff).
> > 
> > Yes.  But, importantly, _not in the snapshot archives that Savannah cgit
> > generates_.
> 
> Why do you insist on using cgit snapshot archives, when everyone else uses
> 'git clone'?
> 
> Everyone uses 'git clone', because when a developer has checked out the
> sources and done a build of groff, the chances are high that they will want
> to a build again, say, two weeks later. By then, you will have updated the
> gnulib repository reference (of the submodule). Thus, the developer will
> need that new snapshot of gnulib. By downloading the cgit snapshot archives
> it will require him 8 MB of download; by doing a "git pull" in the submodule
> it will be something like 0.1 MB. In other words, 'git clone' is prepared for
> incremental updates, whereas cgit snapshot archives are not.
> 
> > After resolving this, I had plans to go complain to the Savannah
> > administrators that the snapshot archives they generate on demand
> > neither (1) recurse through submodules nor (2) provide a
> > ".tarball-submodules" file with the requisite information such that
> > users can construct URLs and retrieve those bits themselves.
> 
> cgit is not developed by the Savannah admins. Are you suggesting that the
> Savannah admins fork cgit?
> 
> > >   - let 'bootstrap' abstain from any git operation; that implies passing
> > >     not only --gnulib-srcdir but also --no-git.
> > 
> > Adding '--no-git' to '--gnulib-srcdir' doesn't seem to change anything
> > for me
> 
> That's because you had apparently no local changes to gnulib. If you have
> local modifications, '--no-git' is essential, if you don't want to get crazy.
> 
> Bruno
> 
> [1] 
> https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=blob;f=Admin/release-steps