Calling autoconf in a spec.

[Sam Varshavchik]

Kevin Kofler writes:

> Sam Varshavchik wrote:
>
> >
> > 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.

Well, I can tell you, as an upstream, when my build distro is updated, the  
existing source trees do not get rebuilt automatically. configure does not  
get triggered, in the existing source trees, to rebuild itself. configure  
and automake-generated makefiles only look at the timestamps of the existing  
files in the source tree, and do not consider the timestamps of the autoconf  
and automake packages.

So, even after a build distro update, autotools do not get regenerated  
automatically. The entire source tree will likely get rebuilt, because all  
the system header files have been touched, but autotools does not regenerate  
automatically.

After things settle down, then I would go in and rebuild all the autotools  
stuff, then test the end results and sign off that the new versions of  
autotools didn't break anything.

They don't break every time, but they do break, and after many autotools  
updates over the many years, the configure scripts did have to be fixed,  
more than once, to work with the new autotools. It's been mostly autoconf.  
Rarely does something changes with automake, or even libtool, or even  
gettext, that breaks things. Most of the time it's autoconf.

But, it does happen with sufficient regularity for me to conclude that just  
rebuilding all the autotools stuff with whatever's on the build platform,  
without considering what upstream is using, and just blindly forging ahead  
without doing any due diligence, is just not stable. Sorry, it's not.

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

Well, I can't speak for every upstream. But, I don't ignore warnings, and I  
don't update my trees to new versions of autoconf arbitrarily. That's a non- 
trivial excersize that, if one wants to do some due diligence.

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

Well, to me it makes much more sense to simply eliminate the uncertainty  
from the process. If I take the tarball that I'm going to build today, if I  
have to rebuild it next year, of a few years from -- the tarball will remain  
the same. It's not going to change. Similarly, if I apply a patch to some  
file in the tarball, if the patch file also is the same next year as it is  
today, then I have a pretty good level of confidence that the end result  
will be the same today, as it will be next year, or even a few years from  
now. In fact, I'm pretty damn sure it will be, and if I'm audited, I will be  
able to prove it.

Unfortunately, if my build process involves running whatever version of  
autotools happens to be present somewhere in the filesystem, then I can't be  
100% sure that the results next year will be exactly, identically the same  
as the results that I'm going to get today. I will not guarantee that the  
results will be the same. You can assert as much as you want, with as much  
confidence as you want, that this is the right way to do, from some  
philosophical viewpoint, but you will not be able to prove to me that you  
will always get the same results.

So, if my goal is to always get the same end results, then I simply cannot  
do that.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110703/b1d9232f/attachment.bin