Calling autoconf in a spec.
kevin.kofler at chello.at
Mon Jul 4 02:09:41 UTC 2011
Sam Varshavchik wrote:
> Kevin Kofler writes:
>> Sam Varshavchik wrote:
>> > Ok, then when you patch configure.in, configure.ac, and/or Makefile.am,
>> > be sure to also specify:
>> > BuildRequires: autoconf=[version]
>> > and
>> > BuildRequires: automake=[version]
>> > in order to have a reproducible build.
>> Nonsense. Even many upstreams do that.
> Can you translate that. It's nonsense because many upstreams do that?
Oops, I forgot the most important word. :-(
Nonsense. Even many upstreams DON'T do that.
Only very few upstreams use a specific version of autoconf and/or automake,
most upstreams will just use whatever version happens to be on the
developer's system that day.
>> (I know I don't. On the autocrap-
>> using projects I inherited, I just run "autoreconf -i -f" with whatever
>> version I have on my system and ignore all the warnings.)
> Sure. You must be able to tell, at a glance, which version of autoconf and
> automake were used by upstream, and what the impact will be as a result of
> rebuilding with, most likely, Fedora's different version, even before
> introducing any patches.
Even upstream itself will generally just run "autoreconf -i -f" without even
looking at the warnings. The warnings are generally such incomprehensible
gibberish that nobody who isn't an autotools developer even understands them
> I mean, after all, autoconf has such a perfect record of 100% backwards
> compatibility, as far as I can remember.
That's exactly why the autotools suck, and upstream projects should be using
a build system which actually cares about backwards compatibility.
But in practice, the right thing to do is to just run "autoreconf -i -f" in
%prep, and fix any issues if they fail the build or get reported by users,
exactly the same way as we handle incompatible GCC changes.
More information about the devel