autoconf and epel-5

[Michael Schwendt]

On Thu, 26 Feb 2009 11:39:36 +0000, Richard wrote:

> On Thu, Feb 26, 2009 at 10:47:07AM +0100, Michael Schwendt wrote:
> > Patches? ... Patches created by regenerating modified autotools
> > input files?
> > 
> > That won't be different from running autotools at build-time. With one
> > exception: you get a chance to examine the patch and verify it and the
> > results it produces -- you can't do that with unattended rebuilds in a
> > build system where the autotools versions may change any time and cause
> > unexpected side-effects.
> 
> In some theoretical world perhaps.

What makes you think so?
My opinion is based on experience.

> In reality though - the patches are full of unintended changes 

Correct. Hundreds if not thousands of changed lines in shell script or m4
code.

> (eg. if there is a change of autoconf), and even if you get a minimal
> patch, it's still a patch to some giant shell script which is very
> hard to verify.

You're not supposed to verify a thousand lines of shell code.
It sufficient if you verify (1) which files get regenerated and (2)
that the build log and the build results are as expected.

> Also in the real world, builds don't tend to break
> because of autotools changes,

It's the contrary. They have caused breakage so often, it lead to
inclusion of multiple releases of various autotools in this Linux
distribution. According to your theory, one could simply have run/used the
latest release of the autotools.

> and if they do, they're much simpler to fix.

That is not what has happened. Access to private albeit not hidden
variables and cache variables, for example, has caused lots of silent
breakage. And that's just one example. We're not talking about trivial
fixes where a function/macro name has changed and is rejected when
re-running the latest autotools.