Re: [groff] I hate git-version-gen

[Ingo Schwarze]

Hi Werner and Bertrand,

Werner Lemberg wrote:

> What do you mean with `reliable testing'?  I've never encountered
> such issues, so please elaborate on your setup.

My usual procedure is to git pull, build a distribution tarball in the
standard way described in INSTALL.REPO, then build an installable
package from that with the standard OpenBSD packaging system, which,
in a nutshell

 1. extracts the tarball
 2. applies distribution patches (minor things like adjusting the
    operating system name and section titles to local conventions)
 3. runs configure
 4. runs make
 5. runs make install to a fake area
 6. uses a packing list to validate that the right files
    got installed in fake area
 7. builds a package from the fake area

This procedure implies testing both the out-of-tree build (for
building the dist tarball) and the in-tree build (when building
the final package).  It also implies that i do testing with the
real, final paths and interdependencies of modules that users
will later on have on their production systems.

I can then install the resulting package into the real operating
system, run regression suites, and do manual run-time testing.

This time, the effects of git-version-gen caused failures in
steps 1, 2, 6, and 7, and at run-time, see below for the reasons.


Bertrand Garrigues wrote on Fri, Mar 16, 2018 at 01:01:26AM +0100:
> On Thu, Mar 15 2018 at 08:34:00 PM, Ingo Schwarze <address@hidden> wrote:

>> git-version-gen is a very serious nuisance.  It efficiently prevents
>> any kind of reliable testing.  It creates totally ridiculous version
>> strings like "1.22.3.rc1.40-1327" which then get scattered all over
>> the place, up to and including absurd directory names like
>>
>>   .../share/groff/1.22.3.rc1.40-1327/font/...
>>
>> but that crap really invades *many* places.

To be more specific:

 1. The name of the distribution tarball.
    (But well, mv(1) is my friend.)
 2. The directory name inside the distribution tarball.
    (I can fix that by an explicit override in the packaging system.)
 3. The share/groff subdirectory name.
    (Hard to fix in packaging, because:)
 4. Lots of hard-coded paths in practically all compiled binaries.
 5. Several string comparisons in perl and shell scripts.
 6. Manual pages and --version output.
    (That doesn't actually matter, i can easily ignore it.)

  $ pwd
  /usr/ports/pobj/groff-1.22.4/fake-amd64/usr/local
  $ grep -RFa 1.22.3.rc1 * | wc -l
  188

It seems like i somewhat overreacted because i just wanted to do some
simple testing, but tripped first over item 2, having that fixed over
item 3, having that fixed in a wrong way over items 4 and 5, then
looking at the build logs, saw 1.22.3.rc1 all over the place, so
assumed there are many more issues similar to 3/4/5 - but apparently,
the path below share/groff is the main, maybe even the only of the
issues that has an impact of this order of magnitude.

Because of items 4 and 5, the only way i found to do testing at all
is a patch like this to configure.ac before building the distribution
tarball:

 AC_INIT([GNU Troff],
-       m4_esyscmd([build-aux/git-version-gen --prefix "" .tarball-version]),
+       [1.22.4],
        address@hidden,
        ...

>>  That way, it is basically
>> impossible to do any serious testing not only because such nonsense
>> causes any packaging system to blow up, but also because all the
>> testing gets completely invalidated once we go back to a sane version
>> name like 1.22.4.  Because who knows whether files are still in the
>> right places, modules can still communicate properly, and modules
>> can still handle the radically changing version string?  And no,
>> invalidating all previous testing is not what you want to do as
>> shortly as possible before release.

> Sorry to hear that you were annoyed by that.  I thought that having a
> unique directory name in .../share/groff/ would not be a problem and
> could help for example to detect a build regression where a file is no
> longer installed (if for example you forgot to uninstall

I doubt that nowadays, anybody still uses the native build system
to install self-compiled software directly into the operating system,
so i don't see how that is relevant...

> and have some
> files from a previous build that are still there), but I understand that
> it can make the comparison of 2 builds harder.

>> Can't we just get rid of that bloat, statically set the version string
>> to 1.22.4 right now, and have the benefit of being able to start with
>> real testing?  Even if a number of commits may still go in, the risk
>> that they break something - almost certainly locally - is much smaller
>> than the risk that the complicated version-gen machinery, which has
>> tentacles almost everywhere, causes or hides fundamental issues,
>> which will then fully impact the final release, and that only.

> While I understand the problem of the install directory in
> .../share/groff (we could easily change that by extracting the first 3
> numbers to build the directory name),

That could only help if you would also fix the version string to say
1.22.4.whatever rather than 1.22.3.whatever for an 1.22.4 release
candidate - right now, the string is "1.22.3.rc1.43-e7a3", with
"3.rc1", even though this is actually a *4* release candidate.

> what's the problem with having the
> various programs printing a unique version (for example with 'groff
> --version')?  Does this bring extra testing difficulties?  Having a
> unique version seems better when people report a bug (otherwise they
> would just say "I'm using 1.22.3" or "I'm using groff from git").

No, that is not a problem at all.  I hardly ever look at the --version
output of anything.  If i want to see what software versions i have
installed, i exclusively rely on the package database.

Yours,
  Ingo