Re: Reproducible, precompiled .o files: what say policy+gpl?
On Tue, Oct 19, 2004 at 02:04:42AM +0200, Wouter Verhelst wrote:
> On Mon, Oct 18, 2004 at 07:02:19PM -0400, Glenn Maynard wrote:
> > You can't take the source, compile it with a proprietary compiler and
> > upload the result to main, because in order to create that package,
> > you need a non-free compiler. The fact that you can also compile the
> > sources with a free compiler is irrelevant; non-free tools are still
> > required to create the package actually in main. Policy doesn't say
>
> If that is important, then we must throw all packages which are built
> using an outdated glibc, binutils, or gcc out of the archive; because
> the tools used to build those packages are no longer in main (no,
> snapshot.debian.net doesn't count); and building something which was
> built, e.g., 4 months ago using the then-current unstable toolchain,
> will not produce the exact same package as it would today -- it would
> produce...
This is a nice attempt at rationalizing parts of the Debian archive
being buildable in their "optimized" form only using non-free tools.
> Your point?
My point is obvious; if you can't understand it, I'm not going to spend
much time trying to force it into you, since I doubt others are having so
much trouble.
> Also, consider the fact that in the past (at least if I'm not mistaken),
> the m68k kernel maintainer used to provide m68k kernel packages built
> using a cross-compiler on his i386 system. Since the cross-compiler
> isn't in main, should those m68k kernels have been moved to the
> 'contrib' archive?
The cross-compiler probably should have been packaged. I don't consider
these comparable issues, anyhow, since the cross-compiler is Free; the tools
needed to build the binaries in question are not.
> > it says "the package in main must be buildable with tools in main".
>
> That is still the case. The fact that the package in main is built using
> non-free tools is irrelevant -- it can be rebuilt using software only in
> main; it can be ran using software only in main; and the difference is
> not noticeable except by comparing checksums, benchmarks, or to those
> with an intimate knowledge in compiler optimizers.
You're playing down "benchmarks" as if they're unimportant, yet the entire
purpose of building with proprietary tools is for speed--clearly the
benchmarks are important. You can't have it both ways.
Being able to rebuild binaries in main is critically important (ie. for fixing
security-related bugs down the line), and the only people who can do so for
this package are the people with these proprietary tools. I suspect you'd
have difficulty getting such an update into a stable release *at all* if the
only way you could do so required halving the speed of the program (and
possibly introducing bugs) due to a changed compiler.
--
Glenn Maynard
Reply to: