Re: Autoconf, snapshot builds, git-version-gen, and groff's version number

[G. Branden Robinson]

Hi Ingo,

At 2022-05-28T17:00:46+0200, Ingo Schwarze wrote:
> G. Branden Robinson wrote on Fri, May 27, 2022 at 01:29:11PM -0500:
> 
> > Does anyone have any ideas for how we might surmount this issue?
> 
> Certainly not by piling yet more overengineering on top of all the
> overengineering we already have.  We don't need ten different ways
> to download and build groff.

The challenge I feel myself facing is that the Savannah/cgit Web
interface makes these snapshots available whether we, the project
developers want to expose them or not.  I don't know if they can be
switched off, if I have administrative permission to do so if they can
(I doubt it; I have an administrator bit only on the issue tracker as
far as I know), or if making this property configurable would require
code changes to Savannah/cgit.

So, you see, it seems like a bit of a long pole.  And a downloadable tar
file corresponding to a Git revision isn't a stupid thing to want.  Git
is popular but it is not ubiquitous; working snapshot builds would make
our development more accessible to those who must, or choose to, do
without it.

And as far as I know, we don't have ten different ways.  We have three,
one of which doesn't really work.

> Having one way that is simple and reliable is better.

I don't see how we're going to get that number below two.

> For releases, tell people to download tarballs.  They already work
> as intended, nothing to fix there.
> 
> If people want to play with unreleased code, tell them to use git(1).
> It provides all kinds of useful functionality for that purpose (and
> more), for example switching to any desired commit.  Supporting
> neither-fish-nor-fowl stuff is not only pointless but harmful because
> it wastes development time and introduces new opportunities for bugs.

I somewhat sympathize but this argument needs to be taken to people who
can do something about it.

> I already consider "git describe", "git-version-gen" and anything
> related to it as overengineering.  When using a release, it is not
> needed at all.  When an OS packager packages a release but applies
> a minimal set of OS-specific patches (which is very common and
> reasonable), it doesn't help at all because those patches are not
> in the groff git repo, so if the packaging system requires modifying
> the version number (usually by appending to it), packagers usually
> do that using tools specific to their packaging system.

Okay.  These, too, are not matters I am situated to influence without
appearing amid Git or gnulib development, respectively, and griping
about them.  I enjoy some utility from both, though I would not rule out
alternative means of satisfying my needs.

> If somebody compiles from arbitrary git commits, *no versioning
> is needed* because such stuff is either needed only for development
> purposes or purely private.

Versioning _is_ needed because the groff language requires the .x, .y,
and .Y registers to be populated at build time.

> Stuff compiled from arbitrary git commits will never be used in
> packaging systems nor be distributed to end users.

It's like you've never met a Gentoo user.[1]

> So this whole git-version-gen complexity solves an imaginary problem
> that does not exist in the first place.  Its only benefits are being
> excessively complex and creating yet more imaginary follow-up problems
> like this one.

I'll have to try Ralph's suggestion regarding git-version-gen's
--fallback option; I had already made one attempt, but maybe I
misunderstood or misused it.

If we could solve the problem I raised in my OP, and if the
Savannah/cgit snapshot generator would produce (along with
".tarball-version") the output of "git submodule", say in
".tarball-submodules", or bundle those same submodules in the generated
archive, I have no reason at present to suspect that snapshot archives
would not be perfectly serviceable.

Regards,
Branden

[1] https://knowyourmeme.com/photos/298801-install-gentoo

signature.asc
Description: PGP signature