Suggested packaging guideline: avoid running autoreconf

[Braden McDaniel]

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.

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