autoreconf vs patching

[Ralf Corsepius]

On Sun, 2005-02-13 at 19:03 +0100, Michael Schwendt wrote:
> On Sun, 13 Feb 2005 16:49:36 +0100, Thorsten Leemhuis wrote:
> 
> > Am Sonntag, den 13.02.2005, 09:15 -0500 schrieb Toshio:
> > > On Sun, 2005-02-13 at 12:28 +0100, Thorsten Leemhuis wrote:
> > > > Adrian, cause there might be problems due to different autotools-
> > > > versions we normally (at least AFAIK) solve this not by a autoreconfig
> > > > in the spec file. We instead create a patch after running autoreconf -i
> > > > -f against an unmodified src-tree and but the patch in the spec file.
> > > > See sirius/sirius.spec for an example. Remember to remove the autoreconf
> > > > cache-dir autom4te.cache/ before diffing.
> > [...]
> > > Thorsten -- what exactly are you thinking of in terms of version
> > > mismatch?  
> > 
> > Well, I have no strong option here. I only do it that way after a
> > discussion on IRC where someone said: 
> > 
> > "if you find a need to update files, you should create patches for them,
> > and apply them in the spec file, instead of assuming whatever version of
> > autoconf, automake, libtool and any other macro-providing package is
> > going to do the right thing at any later point in time"
> > 
> > and I and some others agreed on that. 
> 
> If it works for you...
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 :(

2. Running autoreconf is error-prone and can break packages in subtile
and hard to find ways.

In probably >> 90% of all cases it will work without too many problems,
but those cases it doesn't work out often are even hard to recognize.
(I.e. you only think autoreconf worked, while it actually failed.) 

When using patches, you very likely recognize these cases and will be
able to fix them.

> The important thing is to make sure that the upstream developers update
> their autotools files soon, so you don't need to recreate the patches for
> every minor version upgrade.
ACK, but ... besides broken configurations, the number one reason for
having to rebuild autotool-generated files on RH system probably is RH's
libtool, because vanilla libtool does not support multilibs.
I.e. many source packages which have been packaged on non-RH systems,
require "libtoolize" to be able to build for multilib'ed RH-
architectures. This then can pull-in a chain of further dependencies,
esp. with source-packages sticking with obsolete versions of the
autotools (E.g. many Gnome packages).

All in all, I consider using patches instead of "autoreconf"'ing to be
the only acceptable approach and therefore consider running autoreconf
inside of a spec to a bug.

Ralf