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... > > "you must be be able to build a package similar to the one in main using > > tools in main"; > ...a package similar to the one in main. > Your point? In an ideal world, rebuilding the archive from scratch today would give us an archive with byte-for-byte identical contents. In the real world, this is clearly impossible because nothing stays still long enough to make such routine bootstrapping feasible -- especially on our slower archs, but even on our fastest archs it would be a maddening exercise. This doesn't make the *goal* of reproducible binaries irrelevant; indeed, if pushing 11 architectures up the hill towards release at the same time weren't already a sisyphean task, I think it would be a good idea to actually make such a bootstrap part of the release cycle once sources are frozen. As it stands, we just have to draw the cutoff line somewhere more reasonable, i.e., requiring rebuilt packages to be *functionally* indistinguishable. > 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? A cross-compiler and a native compiler built from the same toolchain sources *should* give identical output for all inputs. I'm personally willing to assume that this is true for current gcc/binutils in the archive, and treat such cross-compilers as another legitimate shortcut like ccache or distcc, unless shown otherwise. If he were using a cross-compiler that was not kept in sync with the packages in unstable, however, I would *not* accept the premise that the binaries are identical to those built by the current gcc; uploading such binaries would unnecessarily complicate the debugging process, and could even hide bugs when trying to build the sources with a current compiler. I would say that such binaries should not be uploaded at all unless it can be reasonably shown that building with the official toolchain produces the same output (which basically requires *using* that toolchain for building, so there's no point in not uploading those binaries directly). > > 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. > A difference in optimization is not relevant to a package's freedom. If compiling the program with a non-free compiler gains you users who would not find the package usable otherwise, distributing binaries built with such a compiler induces your users to be dependant (indirectly) on non-free software. That is a freedom issue. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature