[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
signature.asc
Description: PGP signature
- Re: autoreconf --force seemingly does not forcibly update everything, Eric Blake, 2024/04/01
- Re: autoreconf --force seemingly does not forcibly update everything, Bruno Haible, 2024/04/01
- Re: autoreconf --force seemingly does not forcibly update everything, Jeffrey Walton, 2024/04/01
- Re: autoreconf --force seemingly does not forcibly update everything, Guillem Jover, 2024/04/01
- Re: autoreconf --force seemingly does not forcibly update everything, Bernhard Voelker, 2024/04/10
- Re: autoreconf --force seemingly does not forcibly update everything, Bruno Haible, 2024/04/10
- Re: autoreconf --force seemingly does not forcibly update everything, Bernhard Voelker, 2024/04/10
- Re: autoreconf --force seemingly does not forcibly update everything, Simon Josefsson, 2024/04/10
- Re: autoreconf --force seemingly does not forcibly update everything, Paul Eggert, 2024/04/10
- Re: autoreconf --force seemingly does not forcibly update everything, Jeffrey Walton, 2024/04/10
- Re: autoreconf --force seemingly does not forcibly update everything, Simon Josefsson, 2024/04/11
- Re: autoreconf --force seemingly does not forcibly update everything, Nick Bowler, 2024/04/10