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@endoframe.com>
<http://endoframe.com> Jabber: <braden@jabber.org>


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sat October 11 2008, 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.

There is a draft about this at:
https://fedoraproject.org/wiki/PackagingDrafts/AutoConf

> 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.

I have read either in the wiki or on this mailing list, that one should run
autoreconf locally and create a patch from this, that is then used within the
spec.

Regards,
Till
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Braden McDaniel <braden <at> endoframe.com> writes:
> Rather than patching configure.[ac,in] and Makefile.am, a more resilient
> approach is to patch the configure script and Makefile.in files.

Patching only the generated files is a hack which cannot be submitted upstream,
so usually you end up with a patch which touches both source files and
generated files, and that's a very fragile approach as:
* often you have to run "touch" on generated files which are not affected by
the source change at all, because otherwise the autotools will try to be
smarter than you and regenerate everything because not all generated files are
up to date, and fail if the required autotools for regenerating everything are
not there, and
* such patches generally have to be copied from the sources to the generated
files by hand, because (as I explained in the other thread) regenerating them
generally results in huge patches due to subtle autotools version differences,
which then fail to apply to new upstream versions.

(This is exactly why generated files in source tarballs are a major PITA and
the autotools are broken by design.)

Kevin Kofler

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Sat, 2008-10-11 at 20:31 +0200, Till Maas wrote:
> On Sat October 11 2008, 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.
>
> There is a draft about this at:
> https://fedoraproject.org/wiki/PackagingDrafts/AutoConf

Thanks. I've edited this a bit to include references to libtoolize. I'd
be happy to help move this forward. What's required?

> > 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.
>
> I have read either in the wiki or on this mailing list, that one should run
> autoreconf locally and create a patch from this, that is then used within the
> spec.

That is, generally, the right idea. However, autoreconf is a bit of a
sledgehammer and can result in a patch that is larger than necessary.
The only files that should need patching are configure and Makefile.in.
autoconf will produce the former, and automake the latter. It is more
unusual, but possible, that ltmain.sh might need patching. libtoolize
can be used to generate a patch in that case.

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


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list