Suggested packaging guideline: avoid running autoreconf

Braden McDaniel braden at
Sat Oct 11 18:07:59 UTC 2008

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, a more resilient approach is to patch
the configure script and files.

Braden McDaniel                           e-mail: <braden at>
<>                    Jabber: <braden at>

More information about the fedora-devel-list mailing list