autoreconf vs patching

Toshio Kuratomi toshio at tiki-lounge.com
Tue Feb 15 19:10:35 UTC 2005


On Tue, Feb 15, 2005 at 05:02:35AM +0100, Ralf Corsepius wrote:
> On Mon, 2005-02-14 at 08:18 -0500, Toshio wrote:
> > On Mon, 2005-02-14 at 10:32 +0100, Ralf Corsepius wrote:
> > Re: including patches for autotools generated files.
> > > IMO, this is the only feasible approach, for 2 reasons:
> > > 1. This is how the autotools are assumed to be used.
> > > 
> > > Packagers are not supposed to run any of them when building a package.
> > > If you find you can't avoid running them, something inside of the
> > > package is broken - Unfortunately there are many broken and mal-designed
> > > package configurations out there :(
> > > 
> > Here here.  I think the problem is that autotools are the means by which
> > software is made portable but most software developers have only a few
> > systems types on which to develop... so it's the distro packagers of
> > their software (us) that end up fixing the autotools scripts to work.
> Yes, but ... how many times do you end up adjusting sources for other
> tools?
> 
> The autotools are developer tools like many others, so similar to you
> having to fix broken/incompatible c/c++ code, adjusting hard-coded
> paths, broken scripts etc. you'll have to cope with them.
> 
> I.e. the "right way" to deal with such problems would be to get these
> packages fixed upstream or not to package these packages ("We can't
> package your package is broken and needs to be fixed").
> 
I agree that the packages need to be fixed upstream.  However, if we want a
piece of software in for FC3 and the next release is in 6 months, aren't we
stuck fixing the problems ourselves and sending the patches we generate
upstream?  (Unless we can backport from upstream, of course.)  This is
something that is up to the volunteer offering to package the software --
"I'm willing to spend time fixing the auto-tools scripts" or "I've got other
software I want to get in... I'll report the bug and wait for the next
version."

> >   If you have some
> > redhat/fedora.us bugzilla entries or some examples of how autoreconf
> > messes up, I'd like to look at them so I can understand how things break
> > and how patching would make spotting the errors easier.
> Well, it basically is a matter of complexity.
> 
> Typical examples for case when autoreconf can break things are
> 
> * Running autoreconf on configurations using advanced autoconf tricks to
> setup configuration subdirectories or mixing versions of autotools
> across configuration subdirs. 
> Somewhat oversimplifying: Using autoreconf becomes dangerous when a
> package consist of several subpackages.
> 
But running autoreconf on each subpackage should alleviate this aspect,
right?  (It doesn't address the ramifications of this though... that one
subpackage may be okay to run with the latest autotools while another may
require an earlier version... but see below)

> * Running autoreconf will run the currently installed of current
> autotools. In cases configurations have been written using
> older/obsolete versions of the autotools, this can introduce behavioral
> changes or even break configurations, because the autotools have changed
> their behavior or because a package author might have exploited
> autotools internals which meanwhile have changed.
> 
Which is, however, a bug that should be patched in the configure.ac/etc and
sent upstream, yes?  Or else requiring specific versions of auto* in the
builrequires?

The advantage of upstream doing this is they may have some knowledge that
moving from automake-1.5 to automake-1.6 broke the build in this way and can
check if that happens here as well.  The advantage of packagers fixing this
is we see a lot of autotools breakage and may be able to spot the proper
fixes more easily.

> * Running autoreconf on configurations having been created by
> customized/modified/hacked autotools.
>  E.g. RH's libtool is such kind of "hacked" autotool, i.e. running a
> non-RH libtool on configurations having been created by RH-libtool can
> break a package - Of cause this will not hit you on RH-based systems :)
> However, others also use similar "modified/customized" autotools and
> ship scripts having been generated by these tools, so you are likely to
> trip problems related to the "hacks" they apply.
> 
But this implies that we are commonly going to have to run the autotools on
our packages anyhow, yes?

> * Like any other tools, autoreconf is not bug-free. It is known to fail
> due to bugs in some cases (c.f. autoconf's CVS).
> 
True, but what's the difference for this case when running a buggy autoreconf
and generating a patch of the output vs running autoreconf in the spec file?

Which is my basic question for any of these points.  How is running
autoreconf, generating a patch, and then applying that patch from the spec
file more robust than running autoreconf from the spec file?

> If you want to see some of these problems, take a complex source-tree
> and try autoreconf on them. One case to try would be running autoreconf
> on packages or sub-packages from the "uberbaum", e.g. GCC, binutils,
> snavigator. insight, gdb etc.
> 
Will do.

Thanks,
-Toshio




More information about the fedora-extras-list mailing list