Suggested packaging guideline: avoid running autoreconf

[Braden McDaniel]

On Mon, 2008-10-13 at 09:16 -0400, Adam Jackson wrote:
> On Sat, 2008-10-11 at 14:07 -0400, Braden McDaniel wrote:
> > When the estimate of "300 broken packages" was tossed out in the libtool
> > 2.2.x thread, I figured there was no way *that* many packages could be
> > running autoreconf or libtoolize.  But I have been surprised to find no
> > advice against this practice in Fedora's packaging guidelines; and in
> > light of that, the number is not quite so incredible.
> > 
> > While forbidding the use of autoreconf (or similar: autoconf, automake,
> > libtoolize, etc.) in specfiles is probably too extreme, I do think it's
> > appropriate for the packaging guidelines to point out the pitfalls of
> > this practice and advise packagers to avoid it where possible.
> > 
> > So what are those pitfalls? By running autoreconf, the RPM build becomes
> > exposed to different versions of autoconf, automake, and libtool than
> > were used by the upstream developer to create the upstream source
> > package.  Newer versions of these tools have the potential to introduce
> > incompatibilities, breaking the RPM build.  Rather than patching
> > configure.[ac,in] and Makefile.am, a more resilient approach is to patch
> > the configure script and Makefile.in files.
> 
> No thanks.  Patching Makefile.am at least stands a chance of applying
> correctly across multiple releases of the package.

Patching Makefile.in stands a reasonable chance of that, too.  Exactly
what the odds are depends greatly on the nature of the change; and it is
certainly the case that for a class of changes, the patch to Makefile.am
is more likely to apply cleanly.  Your implication that a patch to
Makefile.in stands no chance of applying cleanly to future releases is
simply hyperbole.

>   Worse, patching the
> generated files stands a good chance of missing an instance of whatever
> you were patching for when the next release comes out.

I think the claim of such a "good chance" is, once again, hyperbole.
Sure, there's *some* chance.  And there's *some* chance of that
regardless of what you file patch.  Again, just what sort of increase to
the likelihood of failure we're talking about depends greatly on the
nature of the change.

> Packages change version much more often than libtool changes version.
> I'd rather go with the method that's resilient against the more common
> change.

If you ran autoreconf, you also need to worry about upgrades to autoconf
and automake in addition to libtool.  Still, there are certainly
packages that have more frequent releases than all three of those put
together.  So from the point of view of an individual maintainer, I see
where you're coming from.  But I have a problem with the practice of
regenerating these files when the broad application of this practice
winds up presenting a serious impediment to upgrading one of these build
tools in Fedora.  That didn't have to happen.

But if all you did was run "automake", I'm pretty sure upgrading libtool
won't break your package.  In fact, I'm not even sure that running
"autoreconf" (without arguments) is sufficient to incur breakage.  What
is nearly guaranteed to cause breakage is running "autoreconf -f".  And
not only is it likely to cause breakage, it's going to be completely
unnecessary in all but *very* unusual cases.

I can accept that my objectives for resiliency may not be shared by all
packagers.  I think it's possible to craft a guideline that steers
packagers toward less deleterious invocations of the autotools (when
they feel the need to do so at all).  But before trying to make any
further progress on this, I want to have a look at the packages that a
libtool2 upgrade stands to break.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>