[Rpm-maint] [draft] spec file unification: autotools based projects

[Ralf Corsepius]

On Fri, 2008-07-18 at 11:32 +0200, Stanislav Brabec wrote:
> Hans de Goede wrote:
> > Ralf Corsepius wrote:
> > > On Thu, 2008-07-17 at 17:09 +0200, Stanislav Brabec wrote:
> > >> Hallo.
> > >>
> > > 
> > >> %build
> > >>
> > >> Packagers are encouraged to call autoreconf whenever possible. It
> > >> guarantees correct build of packages on platforms, that was not
> > >> supported by autotools in the time of the source release.
> > >>
> > >> autoreconf -f -i
> > > 
> > > I vehmently disagree, because this contradicts the autotools' working
> > > principles: The autotools are not supposed to be run during building a
> > > package. The files they generate are supposed to be shipped as part of
> > > the tarball.
> > > 
> > > In practice, your recommendation is causing massive problems and is
> > > harmful on many occasions, esp. with improperly implemented
> > > auto*sources.
> > > 
> > 
> > I agree, blindly calling autoreconf is BAD really really BAD (take it from 
> > someone who maintanis 200 packages). Often the autoreconf input files were 
> > written for different versions of autofoo then are available in the buildsys, 
> > also as Ralf says this goes against the design principles of autofoo. I've 
> > often taken over packages from other people, and removed calling autoreconf and 
> > instead patch both the .am and .in manually (so that if autoreconf ever gets 
> > called again the patch sticks around), fixing many bugs that way.
> > 
> > Calling autoreconf more often _causes_ problems then that it solves them. If a 
> > package _needs_ an autoreconf for bugfixes in newer autofoo versions, upstream 
> > is the place todo this, not during package build!
> 
> Well, we are in a different situation. For people preparing packages for
> i586 and x86_64, there is no benefit for calling autoreconf: Fix nearly
> never happens (as most developers use ix86 for testing), fixing
> not-working autoreconf needs some work and it even rarely causes
> breakage.
> 
> If you are building packages for platforms like s390x, ppc64 or iwmmxt,
> the situation is exactly reverse:
> Without calling autoreconf, many packages fail to build shared libraries
> or fail on obscure errors. Calling autoreconf and porting it to the
> latest autotools is far the simplest solution here.
I have to disagree, again:

1. We are not in different positions. You might not be aware about it,
but Hans, Bill and I all package many packages in Fedora, comprising
more than i386 and x86_64.

2. If what you claim was true, either the packages you are dealing with
are of low quality or there is something very broken with the autotools
integration of the distro you are using.

> 1) We can define different rules for caling autoreconf:
> 
> - If you decide to call autoreconf in your spec file, you should verify
> that it works with the latest autotools suite.
This is pointless, because the autotools might have been updated since
the last built. 

Only patching both sources and generated files guarantees deterministic
behavior of building.

>  If
> you need to modify auto-generated configure script, modify its source
> instead and call autoreconf.
Disagreement again.

Try this on any "non-trivial" package. If you want to see extremal
cases, try this with older gccs, binutils, gdbs or firefox/mozilla.

> 2) We can provide less invasive technique. I openSUSE, it is
> %suse_update_config and %suse_update_libdir:
Well, I am far from being excited about this proposal.

Package maintainers should not need much more but:

%configure
make 
install DESTDIR=...

Ralf