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.
Attachment:
pgp7grn04i0aT.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
