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
