bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: autoreconf --force seemingly does not forcibly update everything


From: Sam James
Subject: Re: autoreconf --force seemingly does not forcibly update everything
Date: Tue, 09 Apr 2024 23:06:58 +0100
User-agent: mu4e 1.12.2; emacs 30.0.50

Bruno Haible <bruno@clisp.org> writes:

> Nick Bowler wrote:
>> 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.

This reads as taking it a bit personally to me.

Nick poses that a specific combination of tools is what is tested and
anything else invalidates it. But how does this work when building on a
system that was never tested on, or with different flags, or a different
toolchain?

It's reasonable to say "look, if you do this, please both state it
clearly and also do some investigation first to see if you can reproduce
it with my macros", but I don't think it's a crime for someone to
attempt it either.

It also has value in the context of software which is no longer
maintained but needs to work on newer systems.

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?

>   * It increases the number of bug reports that reach upstream and yet
>     are caused by the distro.
>   * In the long run, the upstream maintainers will be less willing to
>     handle bug reports from users of this distro.
>

I do sympathise with these points and also that it might be
overwhelming given it removes the ability to fix some elements of the
build environment. Right now, you can at least assert that it builds in
a diverse set of places based on what you tested.

> Bruno

thanks,
sam

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]