Sam James replied to Bruno Haible who cited Nick Bowler:
> >> If I distribute a release package, what I have tested is exactly what is
> >> in that package. If you start replacing different versions of m4 macros,
> >> or use some distribution-patched autoconf/automake/libtool or whatever,
> >> then this you have invalidated any and all release testing.
> >
> > +1
> >
> > Last month, I spent 2 days on prerelease testing of coreutils. If, after
> > downloading the carefully prepared tarball from ftp.gnu.org, the first
> > thing a distro does is to throw away the *.m4 files and regenerate the
> > configure script with their own one,
> > * It shows no respect for the QA work that the upstream developers have
> > put in.
> ...
> Nick poses that a specific combination of tools is what is tested and
> anything else invalidates it.
Correct. When an upstream developer/tester has tested a tarball in N
situations, then that tarball is what - he can guarantee - works. The
more changes a distro applies, the more they do so on their own risk.
> But how does this work when building on a
> system that was never tested on, or with different flags, or a different
> toolchain?
The interface of GNU 'configure' [1][2] accommodates for these cases.
In most of these cases, it is not needed to rebuild 'configure'. Just
set CC, CFLAGS, LDFLAGS etc.
- For other systems: see [3].
- System that is still in development: Replace config.guess, config.sub,
and potentially config.rpath with modified variants.
- Different flags: That's what CFLAGS, CXXFLAGS are for.
- Different compiler: E.g. clang on Ubuntu 22.04
CC="/inst-clang/17.0.4/bin/clang -Wl,-rpath,/inst-clang/17.0.4/lib"
CXX="/inst-clang/17.0.4/bin/clang++ -I/usr/include/c++/11
-I/usr/include/x86_64-linux-gnu/c++/11 -L/usr/lib/gcc/x86_64-linux-gnu/11
-Wl,-rpath,/inst-clang/17.0.4/lib"
- Different linker: E.g. to link with 'mold' instead of 'ld',
create a directory /alternative-ld/with-mold that contains a symlink
ld -> /.../bin/mold
and use CC="gcc -B/alternative-ld/with-mold".
On exotic systems with non-ELF binary format, modifying libtool.m4 is needed.
But most distros are not in this situation; they use the glibc or musl dynamic
loader, hence they don't need libtool.m4 changes.
> It also has value in the context of software which is no longer
> maintained but needs to work on newer systems.
Granted; that's a different category of situation. Here a distro will
probably not only need to change *.m4 files but also *.c files. And
hopefully submit the changes upstream.
> We don't apply this rule to anything else -- you've never rejected a
> report from me because I have a newer version of a library installed
> like openssl or similar. Why is this different?
As an upstream maintainer, I have chosen (or, well, GNU has chosen for me,
even before I was present) to give *tarballs* to my users, not git
repositories. The main differences are that
- tarballs contain some generated files for which we want to spare
the user the need to install special tools and get familiar with
them (code generators, doc formatters [texlive, doxygen, ...] etc.)
- tarballs contain source code from other packages (git submodule,
parts of gnulib, etc.)
- tarballs contain localizations, which are maintained elsewhere than
in the git repository (e.g. in translationproject.org or weblate
instances).
Experience has shown that this interface (tarballs with configure
script) allows for relatively effective support.
There are an entire bunch of questions from users of a git repository
(from "can you please commit the formatted documentation into git?"
over "how to I pull in the submodules?" to "why do I get this error
from flex?") that are obsoleted by this interface.
Also, too often people have reported problems with older versions of
the tools. I mean, we are at Automake 1.16.5, and if someone wants
to rebuild my package with Automake 1.13.4 because that's what his
distro is carrying, and they encounter problems, it is just a waste
of upstream developer's time. Old bugs in old versions of the tools
have been fixed. As an upstream maintainer, I don't want to support
- different versions of Automake,
- different versions of Bison,
- different versions of texinfo,
- different versionf of groff,
- etc.
I have enough work supporting
- different versions of the OS (glibc, Cygwin, etc.),
- different versions of GNU make,
- different versions of gcc and clang,
- different versions of packages with optional support (--with-* options),
- ...
Keep the test matrix small!
Bruno
[1] https://www.gnu.org/prep/standards/html_node/Configuration.html
[2]
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/html_node/Preset-Output-Variables.html
[3] https://gitlab.com/ghwiki/gnow-how/-/wikis/Platforms/Configuration
