autoconf and epel-5

Ralf Corsepius rc040203 at freenet.de
Mon Mar 2 17:42:49 UTC 2009


Horst H. von Brand wrote:
> Ralf Corsepius <rc040203 at freenet.de> wrote:
>
> [...]
>
>   
>> Correct - I didn't mean to offend Tom, but it's obvious, that some
>> people around in this thread don't understand the autotools.
>>
>> If people were understanding them, they would not run the autotools
>> inside of rpm.specs but would apply patches.
>>     
>
> Please enlighten us.
>
> AFAIU, the objective of autotools is to detect the environment's quirks
> and configure the package accordingly. They were designed to take a set
> of input files, and creating the configuration (and Makefile) for the
> package on the fly.
>   
Right.
> In view of the above, it does make sense to run them when installing.
>   
Exactly this is the misunderstanding: You run the generated files when 
building a package, but are not supposed to run the generators.

> As Fedora is (mostly) made up of new(ish) packages, so there should be
> few problems with version skew.
>   
In an ideal world, you would be right, there should not be much risks in 
running the autotools when building

Real world, however is different:

* Like any other tool, some versions of the autotools contain bugs
=> Blindly rerunning the autotools at build time (esp. with different 
versions as the original authors do) introduces non-determinims and 
carries risks.

* Many (esp. older) configuration files (configure.in/ac, Makefile.am) 
are only "appear to be working", while they actually are "plain broken". 
Many of the syntax changes of the autotools' originate from tightening 
the syntax to avoid such "silent bugs".
=> In many cases, an autotool upgrade will kill "formerly seemingly 
working" configuration files.

* Many configurations are not prepared for "autoreconf" etc.
E.g. GCC, binutils, gdb, firefox ... fall into this category. Running 
autoreconf kills them.

To cut a long story short: To assure deterministic builds, you must not 
run the autotools when building.

Ralf






More information about the fedora-devel-list mailing list