URL: <https://savannah.gnu.org/bugs/?68563>
Summary: explore support for "artifact-free" builds and
manual groff version number specification
Group: GNU roff
Submitter: gbranden
Submitted: Sat 25 Jul 2026 07:11:53 PM UTC
Category: General
Severity: 1 - Wish
Item Group: Build/Installation
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Unlocked
Planned Release: None
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Sat 25 Jul 2026 07:11:53 PM UTC By: G. Branden Robinson <gbranden>
[https://lists.gnu.org/archive/html/groff/2026-07/msg00013.html Phong wrote of
a build scenario] appealing to those who attempt to minimize use of
"artifacts" (roughly, files in a source release that are not directly
human-maintained). I speculate that one of the reasons people are interested
is to minimize surface area exposed to an
[https://en.wikipedia.org/wiki/XZ_Utils_backdoor XZ Utils backdoor-style
attack].
The discussion sprawled considerably, so here's my summary of the backbone of
it as applied to this ticket.
I'm trying to switch to building from Git
(we are trying to avoid artefacts like generated configure
where possible) and without the .git directory
(which is not reproducible) configure is failing to find
the version:
configure flags: ("CONFIG_SHELL=.../bin/bash"
"SHELL=.../bin/bash"
"--prefix=...groff-1.25.0.rc2"
"--enable-fast-install"
"--docdir= groff-1.25.0.rc2-doc/share/doc/groff"
"--build=x86_64-unknown-linux-gnu")
configure: WARNING: unrecognized options: --enable-fast-install
checking that groff version string has valid format... invalid
configure: groff's version string must start with three decimal
integers separated by dots. "" does not match.
Later, [https://lists.gnu.org/archive/html/groff/2026-07/msg00016.html Phong
elaborated].
I'm speaking for the automated build pipeline here. On Guix,
if a package is built from a Git checkout, a fresh clone
would be made, then the .git directory shall be removed,
hence the following won't work.
On 2026-07-21 at 00:35-05:00, G. Branden Robinson wrote:
> The rules for generating these files are as follows.
>
> $ nl -ba Makefile.am | sed -n 872,874p
> 872 # Version files - see script "build-aux/git-version-gen".
> 873 .version:
> 874 $(AM_V_GEN)echo $(VERSION) > $@-t && mv $@-t $@
On 2026-07-21 at 00:40-05:00, G. Branden Robinson wrote:
> Earlier in the file.
>
> $ nl -ba Makefile.am | sed -n 509,509p
> 509 # 'VERSION' is generated by gnulib script git-version-gen
I've resulted to writing to .tarball-version instead
and the build and tests succeeded. Please let me know
if this has any unintended effect.
[https://lists.gnu.org/archive/html/groff/2026-07/msg00017.html I replied.]
None that I know of, but I'm nervous about the practice. If your build
from the repository is failing to properly populate ".version", I'm
strongly interested to know the failure mode.
[https://lists.gnu.org/archive/html/groff/2026-07/msg00018.html Phong followed
up to sketch the shape of a potential solution.]
IIUC, both .version and .tarball-version comes from $VERSION,
which in turn is derived from the current Git HEAD in .git.
TBH manually populating a version file is not unusual practice in Guix,
though it'd be lovely if the configure script excepts a --version=...
override flag. If that sounds good, I don't expect it in 1.25,
and can offer a patch.
[https://lists.gnu.org/archive/html/groff/2026-07/msg00019.html I responded].
>> The .version file is not placed in the ".git" directory,
>> but the root of the build tree
>
> I was referring to the git-version-gen script, which needs .git to
> determine the current tag/commit.
Ah. In that case your build is neither fish nor fowl: neither a build
from a distribution archive, nor a build from a Git working copy,
because there is no working copy.
What is the rationale for this sort of build configuration?
We've had problems supporting that sort of thing in the past.
https://lists.gnu.org/archive/html/groff/2022-06/msg00001.html
The consensus at that time was not to support them, hence the disabled
"snapshot tarballs" via Savannah's cgit interface.
...
> IIUC, both .version and .tarball-version comes from $VERSION,
> which in turn is derived from the current Git HEAD in .git.
Ultimately, yes.
> TBH manually populating a version file is not unusual practice in
> Guix, though it'd be lovely if the configure script excepts a
> --version=... override flag. If that sounds good, I don't expect it
> in 1.25, and can offer a patch.
Hmm. If it's that easy, why isn't this already standard practice in
projects using Autoconf? Or is it, and I haven't noticed?
[https://lists.gnu.org/archive/html/groff/2026-07/msg00020.html Phong then
snarfed a potential mechanism from a Guix thread.]
I don't know if it will be easy, I was offerring a hand
understanding it is not a high priority for Groff.
From the linked thread, how about hardcoding in configure.ac
the `build-aux/git-version-gen --fallback' version?
This can be done every time a new version number is added
to the NEWS file.
[https://lists.gnu.org/archive/html/groff/2026-07/msg00023.html I dithered
noncomittally.]
That's not a bad idea. We're down to only 2 places where a hand update
is required, and one of those is going to be essential anyway. If I can
fix the other case, then we'd still be no worse off.
I seem to remember we fooled with `--fallback` in that 2022 groff
thread, though, and ran into problems. Something to do with gnulib...??
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68563>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
