Calling autoconf in a spec.

[Sam Varshavchik]

Kevin Kofler writes:

> Sam Varshavchik wrote:
> > 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.
>
> If you want to always get the exact same results, you cannot build from
> source at all, only ship canned binaries (which would be against Fedora
> policies, for good reasons). GCC changes, Binutils change etc. You just
> don't get the exact same binary again.

Both gcc and binutils are extensively regression-tested. Stuff that was  
compiled years ago, still works.

The same cannot be said of autotools.

Red herring.

-------------- 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/20110704/d15e6c87/attachment.bin