autoconf and epel-5

[Adam Williamson]

On Tue, 2009-02-24 at 14:09 -0800, Toshio Kuratomi wrote:

> > Aside from that, I'd say did you read, and try, the advice you were
> > given in the failure log?
> > 
> > "You have another version of autoconf.  It may work, but is not
> > guaranteed to.
> > If you have problems, you may need to regenerate the build system entirely.
> > To do so, use the procedure documented by the package, typically `autoreconf'."
> > 
> > i.e., see if it works with autoreconf. IMHO it is generally a good idea
> > to use autoreconf rather than just autoconf anyway, because just using
> > autoconf is more likely to fail if, say, we go up a major version of
> > autoconf, and upstream source doesn't have a new release in that time.
> > autoreconf has at least a better chance of succeeding in that situation
> > (though it won't always).
> 
> In the most recent debate, someone said that autoreconf should never be
> run.  Wish you had been there to lend another perspective :-)

I can see that argument in terms of making what the package does
somewhat more reliably reproducible on Joe Random System, but in terms
of what works best in a controlled environment (i.e. within a
distribution's repositories), my practical experience is that autoreconf
is probably a good idea. I do actually have rather a lot of practical
experience in this area, as I rebuilt several hundred very old and
unmaintained packages for Mandriva over the last year or two. I came
across rather a lot of cases where just running 'autoconf' wouldn't work
any more (because you were running autoconf 2.6 on stuff that had been
generated by aclocal 1.4 or something...), but 'autoreconf' - to
re-generate everything - would work. So from my experience of nasty old
crufty code, I would say that 'autoreconf' is somewhat more reliable
than running the individual components. There are times when the scripts
are sufficiently nasty and broken that they won't work with modern
versions of the autotools whatever you do, though.

I can see the argument for patching configure or Makefile.in directly
(rather than configure.ac or Makefile.am ), too. It doesn't upstream and
is rather harder to read, I'd say, but it does have the advantage that
it doesn't depend on the behaviour of the autotools, which changes over
time. Debian's policy is this way, FWIW.

Oh, and thanks to Dan for reminding me that using 'autoreconf -i' is the
best way to do it. Some of the tools fail by default if certain
'required' files are missing. autoreconf -i just creates any missing
files automatically.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net