Re: Reproducible, precompiled .o files: what say policy+gpl?
On Tue, Oct 19, 2004 at 10:39:45AM +0200, Wouter Verhelst wrote:
> No, it is not. What you advocate is essentially that a later compilation
> must result in the exact same binary, disregarding the fact that our
> toolchain will change..
Please review this post:
> > Problems arise if there are differences between what the two compilers
> > build. For example, there might at some point be a bug which only shows
> > up under gcc.
> That is a non-issue. We have 11 architectures; if there is a bug which
> only shows up under gcc, then the software will most likely exhibit that
> buggy behaviour on those 11 other architectures.
No, it's an extremely serious issue. If you upload a security update,
with a one-line patch, the changes should be minimal--but they can be
very major if you change compilers.
> If it does not (i.e., it is a bug which only shows up under gcc on
> i386), then this is a bug in gcc which will most likely be found by
> other applications as well (the strain we put on our compilers by
> compiling some 8GB worth of software is enormous)
So you're actually claiming that recompiling software with a compiler
from a stable Debian release can never introduce bugs. Please refrain
from doing updates to stable Debian releases.
Also, it's just as unacceptable to *fix* bugs accidentally in a stable
release. For example, OpenSSL might have an unknown bug as a result
of a compiler glitch that causes something useful but incorrect to be
allowed. This is not a bug that would be fixed in a stable release.
If a stable update is made later to fix an unrelated security bug, you
wouldn't be allowed to go and fix this at the same time. If you change
compilers, however, you could end up inadvertently doing that, resulting
in undocumented, non-critical changes in a stable package that could
break existing systems, which is something Debian tries extremely hard
> Or what about a developer who modified the gcc code to suit his own
> needs, but did not, as the GPL allows him to do, distribute either the
> source to his modifications or a binary built from his modified source?
This is unacceptable, for the same reasons; nobody else can make a stable
update to the package.