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
