[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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...

> > "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*

> 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

> > 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

Reply to: