[opensuse-packaging] Using autoreconf in %build
Hi, are there any guidelines on using autoreconf in spec-files? Specifically, there seem to be some reasons for overriding the packaged GNU autotools files with an up-to-date version from the target distribution (bugfixes? testing? cool factor?). Whatever, I've got two questions about it. First, I make the latest version of some utilities available for legacy products (as ancient as SLE10), because they can be quite useful on those systems (e.g. kdumpid for getting the crashed kernel version from a dump file). However, these legacy distributions contain ancient versions of GNU autotools and friends, so autoreconf does not work properly when building for those targets (missing features, bugs). The scripts included in the upstream tarball are definitely better. Is it OK if I do _not_ run autoreconf in the specfile? Second, autoreconf adds some build requirements: autoconf, automake and possibly libtool and/or gettext-tools (depending on the actual content of configure.ac). All of these packages are always installed, i.e. autoconf works even if they are not specified in the specfile. Should I add the appropriate BuildRequires to the specfile anyway? Should I avoid adding them? Does it matter? Why? TIA, Petr Tesarik -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Petr Tesarik <ptesarik@suse.cz> writes:
First, I make the latest version of some utilities available for legacy products (as ancient as SLE10), because they can be quite useful on those systems (e.g. kdumpid for getting the crashed kernel version from a dump file). However, these legacy distributions contain ancient versions of GNU autotools and friends, so autoreconf does not work properly when building for those targets (missing features, bugs). The scripts included in the upstream tarball are definitely better. Is it OK if I do _not_ run autoreconf in the specfile?
It is not only OK, but even preferred not to run autoreconf, as long as there is no problem with the included configure script. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 26 Nov 2015 11:46:13 +0100 Andreas Schwab <schwab@suse.de> wrote:
Petr Tesarik <ptesarik@suse.cz> writes:
First, I make the latest version of some utilities available for legacy products (as ancient as SLE10), because they can be quite useful on those systems (e.g. kdumpid for getting the crashed kernel version from a dump file). However, these legacy distributions contain ancient versions of GNU autotools and friends, so autoreconf does not work properly when building for those targets (missing features, bugs). The scripts included in the upstream tarball are definitely better. Is it OK if I do _not_ run autoreconf in the specfile?
It is not only OK, but even preferred not to run autoreconf, as long as there is no problem with the included configure script.
I see. I probably shouldn't have accepted submitrequest 325452 back then (sorry Jan!). I'm going to remove the autoreconf stuff completely (including the libtool BuildRequires that prevents building on SLE10). Thanks, Petr T -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thursday 2015-11-26 12:04, Petr Tesarik wrote:
However, these legacy distributions contain ancient versions of GNU autotools and friends, so autoreconf does not work properly when building for those targets (missing features, bugs). The scripts included in the upstream tarball are definitely better. Is it OK if I do _not_ run autoreconf in the specfile?
It is not only OK, but even preferred not to run autoreconf, as long as there is no problem with the included configure script.
I see. I probably shouldn't have accepted submitrequest 325452 back then (sorry Jan!). I'm going to remove the autoreconf stuff completely (including the libtool BuildRequires that prevents building on SLE10).
Hm? 325452 is impertinent to the question; 325452 does one thing: to create configure if it did not exist yet -- without a configure script present, %configure would not ever run. And if a configure script is already present, the check does no harm. In other words, 325452 is justified to stay, I think. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 26 Nov 2015 13:00:19 +0100 (CET) Jan Engelhardt <jengelh@inai.de> wrote:
On Thursday 2015-11-26 12:04, Petr Tesarik wrote:
However, these legacy distributions contain ancient versions of GNU autotools and friends, so autoreconf does not work properly when building for those targets (missing features, bugs). The scripts included in the upstream tarball are definitely better. Is it OK if I do _not_ run autoreconf in the specfile?
It is not only OK, but even preferred not to run autoreconf, as long as there is no problem with the included configure script.
I see. I probably shouldn't have accepted submitrequest 325452 back then (sorry Jan!). I'm going to remove the autoreconf stuff completely (including the libtool BuildRequires that prevents building on SLE10).
Hm? 325452 is impertinent to the question; 325452 does one thing: to create configure if it did not exist yet -- without a configure script present, %configure would not ever run. And if a configure script is already present, the check does no harm. In other words, 325452 is justified to stay, I think.
Well, yes and no. This submit request started it all: It also added "BuildRequires: libtool >= 2", because (presumably) autoreconf failed otherwise. That part made the package unresolvable in SLE10 (which only ships libtool-1.5). Anyway, while trying to make it build again, I wondered if there was any policy on this topic and I found this macro: https://en.opensuse.org/openSUSE:Packaging_Conventions_RPM_Macros#.25suse_up... I checked a few packages that use autoconf, but none of them was using this macro, but some of them used autoreconf. At this point I was unsure if I'm supposed to use that macro (as suggested by the above-mentioned page), run it unconditionally (like some packages do), run it only on recent distros (like some other packages do), or ignore it and just run %configure (like most packages do). For now, I have completely removed autoreconf from my specfile. Works fine on a few dozen build targets... Petr T -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thursday 2015-11-26 14:04, Petr Tesarik wrote:
I see. I probably shouldn't have accepted submitrequest 325452 back
It also added "BuildRequires: libtool >= 2", because (presumably) autoreconf failed otherwise. That part made the package unresolvable in SLE10 (which only ships libtool-1.5).
I think I now why. libkdumpfile-fallback-for-old-zlib.patch changes configure.ac, which means autoreconf should ideally be rerun, since patching autogenerated files like "configure" can end in a rebase horror. Since configure.ac uses LT_INIT, this prescribes libtool >= 2. The simple way out would be to just substitute LT_INIT with AC_PROG_LIBTOOL in the same libkdumpfile-fallback-for-old-zlib.patch patch, so that you will be able to BuildRequire: libtool >= 1.5. -- And you still can drop the ugly hunks for the generated configure script, since you now have the ability to rebuild configure.ac->configure with the old litool.
Anyway, while trying to make it build again, I wondered if there was any policy on this topic and I found this macro:
https://en.opensuse.org/openSUSE:Packaging_Conventions_RPM_Macros#.25suse_up...
I checked a few packages that use autoconf, but none of them was using this macro, but some of them used autoreconf. At this point I was unsure if I'm supposed to use that macro (as suggested by the above-mentioned page), run it unconditionally (like some packages do)
The macro is somewhat obscure, probably in a way that's sanctioned or not supported elsewhere/upstream, so most people run autoreconf, also because the age of in-distro autotools packages is not as bad as it might have used to be 15 years ago. That, and/or we now have enough automagic masters who know how to make a package work across multiple autotools versions - see for example the libtool 1.5 approach proposed above.
run it only on recent distros (like some other packages do), or ignore it and just run %configure (like most packages do).
configure may find a reason to regenerate itself, and then ignoring won't work. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, 26 Nov 2015, Andreas Schwab wrote:
Petr Tesarik <ptesarik@suse.cz> writes:
First, I make the latest version of some utilities available for legacy products (as ancient as SLE10), because they can be quite useful on those systems (e.g. kdumpid for getting the crashed kernel version from a dump file). However, these legacy distributions contain ancient versions of GNU autotools and friends, so autoreconf does not work properly when building for those targets (missing features, bugs). The scripts included in the upstream tarball are definitely better. Is it OK if I do _not_ run autoreconf in the specfile?
It is not only OK, but even preferred not to run autoreconf, as long as there is no problem with the included configure script.
And even then the preferred way to fix things is to patch the generated files as well. Richard. -- Richard Biener <rguenther@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (4)
-
Andreas Schwab -
Jan Engelhardt -
Petr Tesarik -
Richard Biener