[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Bruno Haible
Subject: Re: git-version-gen not working with Savannah/cgit snapshots
Date: Sun, 05 Jun 2022 23:59:26 +0200

Hi Branden,

> > 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/ 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.

> says this.
> AC_INIT([GNU roff],
>         m4_esyscmd([build-aux/git-version-gen --fallback 1.23.0.rc1 \
>           --prefix "" .tarball-version]),
>         [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,
  (I) git-version-gen and
  (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

Many packages (autoconf, bison, coreutils, diffutils, gettext, guix, gzip,
libidn, libtool, m4, patch, wget, ...) use the following in their

  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 snippet would work,
  - you would not need the --fallback option,
  - and thus you would not need to modify the (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 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]