autoconf/automake in BuildRequires

[Ralf Corsepius]

On Mon, 2005-10-31 at 07:22 -0800, Toshio Kuratomi wrote: 
> On Mon, 2005-10-31 at 15:22 +0100, Ralf Corsepius wrote:
> > On Mon, 2005-10-31 at 15:31 +0300, Dmitry Butskoy wrote:
> > > According to wiki/PackagingGuidelines, there is exceptions list for 
> > > BuildRequires tag:
> > > 
> > > > There is no need to include the following packages or their 
> > > > dependencies as BuildRequires because they would occur too often. 
> > > > These packages are considered the minimum build environment.
> > > >
> > > Autoconf and automake are not present in this list, therefore they must 
> > > be specified in the BuildRequires tag. OTOH it looks as some basic 
> > > tools... May be autoconf and automake should be included in the 
> > > exception list too?
> > Never.
> > 
> > Any package requiring them is _broken_. Such bugs should be reported
> > upstream and fixed there.
> > 
> I agree that they should be reported upstream.  But what happens until
> upstream makes their next release?  No movement on the package?
Yes, that's one possibility to handle such problems: If a package
requires running the autotools, it is broken by definition.
This therefore would be a legitimate reason for not integrating a
package, unless the Fedora maintainer is willing to cope with the mess
the upstream maintainer causes.

>   Or
> truly horrid, unreviewable, thousand-line patches of Makefile.in's?
FUD - If you know what you are doing, configuration patches in many
cases are "few liners". If you blindly run "autoreconf", esp. if you run
different versions of the autotools than the original author, you're on
your own - It's often mere luck if a package "still appears to work".

Also, reviewing the diff having been generated by 2 slightly different
versions of auto*tools (say automake-1.9.4 vs. automake-1.9.6) isn't
much of a problem (They can be large in size, nevertheless they often
are very simple, "repetitive" and not hard to understand).

> Whether running autoconf or patching Makefile.in's is more broken is not
> clear.
To me, there is no doubt: Who blindly runs the autotools on a package,
has no clue about what he is doing.

> > Also running any autotool as part of building a package imposes
> > non-negligible risks to silently break packages.
> > 
> Can this be fixed by pegging which version of automake is needed?

Well, to some extend yes. You are reducing the risk of breaking
something, and are reducing the size of resulting patches.

However, some configuration are sooo broken that you can't exclude
anything.

To me, manually checking the version of autotools being required by a
package when writing a spec file and having to modify the configuration,
is a must (E.g. "BuildRequires: automake17").

> I don't know what problems you are referring to so I'm just taking a
> stab in the dark at a possible solution.
I could write books about it ... 

In a nutshell, the primary sources of problems are these:

1. configuration/Makefile authors are relying on undocumented behavior
of autoconf/automake internals (Fairly common in old autoconf-2.13
configure scripts).

2. Users are relying on proprietary behavior of vendor patches to the
autotools (e.g. Debian autoconf patches, or RH libtool patches).

3. Some behavioral details of the autotools have changed significantly
between different versions of the autotools (That's why these carry
different version numbers - They are not fully backward compatible).
Implicitly upgrading (eg. running automake-1.9 on Makefile.am having
been written with automake-1.4) can have subtile behavioral differences.

The problem with these issues is: In many cases, running FC-autotools
destroys the user-intended behavior, and causes silent errors which are
very hard to find and sometimes tedious to fix - if they hit.

Fortunately (and that's why running autotools often is harmeless.), most
configurations are trivial and either don't break at all or obviously
break when running the autotools.

The critical ones are the "complicated configurations". There
"autoreconf"ing is dangerous (Some examples: binutils, GCC, Coin2,
rtems).

Ralf