On Mon, Oct 18, 2004 at 08:25:48PM -0400, Raul Miller wrote:
> On Tue, Oct 19, 2004 at 01:47:34AM +0200, Wouter Verhelst wrote:
> > The first section of the SC says that Debian will remain 100% Free
> > Software.
>
> That is the title of that section.
>
> If you bother to read it, you'll see "We will never make the system
> require the use of a non-free component. "
A binary which has been compiled using a non-free compiler does not
require non-free software to run; nor does it require the same compiler
to be built again. If it does, then it doesn't belong in main; that is
not in dispute.
Also, if the software compiled using a non-free compiler requires an
additional license from the distributor, then it doesn't belong in main
either; but AIUI, this is not the case (it only requires an additional
license from the person using the compiler).
> > It does not say that the binary bits of Debian can be restored
> > to something which will produce the exact same MD5 sum using only Free
> > Software[1].
>
> This is a straw man argument.
> http://www.nizkor.org/features/fallacies/straw-man.html
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..
> > Since Wesley's software will be released under the GPL, it
> > will clearly be Free Software, so there is no problem.
>
> There is a problem if building that component requires the use
> of a non-free compiler.
Well, it does not /require/ the use of a non-free compiler.
> > The fact that Wesley wanted to build his package using non-free software
> > does not really matter -- as long as it does build using Free software.
>
> It doesn't matter if there is no difference in what is built.
>
> 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.
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)
> > Heck, some developers might have installed icc and might be compiling
> > their packages using that compiler instead of gcc; as long as their
> > software does not use too many gcc-isms, you should not even notice so
> > in the source. How would you tell that such a package is built using icc
> > instead of gcc, other than by benchmarking?
>
> [1] I hope no one is doing that.
I wouldn't care, as long as it would work correctly.
> [2] We probably wouldn't notice this issue until it creates problems.
I don't think it would create problems. See below.
> > If you still insist, consider this: If I would know i386 assembler
> > (which I don't), I could theoretically hand-optimize software before I
> > upload it. Since I did hand-optimization, the resulting binary would no
> > longer be built using only Free Software; it would also incorporate the
> > fruit of my labour. Is the resulting binary now suddenly non-free -- or,
> > at least, should it go to contrib instead of main? If so, why? If not,
> > what's the difference between this example, and the question of
> > icc-built software?
>
> If you've hand optimized it, the hand optimized assembler becomes a part
> of the sources.
Okay, what about this then? The m68k kernel maintainer at one point, if
I'm not mistaken, used to compile m68k kernels with a cross-compiler he
built.
As a result, the compiler used to compile the kernel is not in main.
Does that make the resulting kernel binary non-free?
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?
(where he only modified the optimizer code, not the parser code)
[...]
> > I don't see any reason why we should not consider the resulting builds
> > to be part of main.
>
> If you can guarentee that when the package built with icc is tested
> that any bugs which would result from building using at least one free
> compiler will be evident, and if you can guarantee that systems which
> use icc-built software will continue to function if they use some free
> compiler to build that software then the problem is more philosophical
> than practical.
>
> That said, I don't see any viable way for you to provide any such
> guarantees.
Easy.
I can see three classes of problems that could result in the software
not being usable when compiled by a different compiler than the one used
when the software was distributed:
* The software simply does not compile, due to a parser bug in one of
the compilers; either the code compiles with the used compiler while
it is syntactically invalid, or the code does not compile with the
not used compiler while it is syntactically valid. This is a
non-issue; we compile for 11 architectures, so if this would happen,
we generally would see it due to the fact that the package would fail
to build on a different architecture.
* The not used compiler ICEs when trying to build the binary. This is a
type of, generally architecture-specific, bugs that will show up
/every/ time the package is compiled. When this happens, it really is
a bug in the compiler; however, it can easily be checked by the
maintainer by just compiling the software once using the free
compiler before uploading the software which had been built using the
non-free compiler.
* The software would compile using a different compiler, but -due to an
optimizer or other bug- would not run correctly. If the compiler would
exhibit this behaviour in just one package, this would be an issue.
However, it is my experience that this type of compiler bugs generally
does not show up in just one package; usually, it will break at least
a bit more. Due to this reason, and due to the fact that icc-compiled
packages will be the exception rather than the rule (because you need
to pay to be allowed to use the compiler to distribute software, which
I don't think many of us are eager to do), I anticipate that this
problem will not exist in reality.
As you can see, I don't believe any of these issues can result in
software which is in main, but which will run incorrectly, or not at
all, when built using software only in main. If you can come up with a
different example where there would be an issue, or if you can show that
one of my examples is invalid, then I can agree that it should not be in
main. However, I don't think this is the case.
> > I am fully aware that there are people who think that all non-free
> > software should be banned from the face of the earth (Hi Richard!).
> > However, the fact that some Free Software package is built using
> > non-free Software, even though it could be built using only Free
> > compilers, does not suddenly make the Free Software package non-free.
>
> This is a straw man argument.
>
> The issue isn't banning non-free software from the face of the earth.
>
> The issue is that main is not supposed to depend on non-free software.
I know; but compiling software using non-free compilers does not make
main depend on non-free software, so long as the software does also
compile using free software (which I believe it will)
> > What is 'Free Software' is defined differently by both Debian and the
> > Free Software Foundation; however, GPL'ed source code which is built
> > using a non-free compiler does not, in my view, fail any test of either
> > of those definitions.
>
> I don't have a problem with GPL'd source code.
>
> I have a problem considering the resulting binaries as suitable candidates
> for main.
I do not, so long as they compile correctly using a free compiler (which
I believe they will)
> > Policy and the Social Contract may not, and IMO do not, conflict.
>
> Agreed.
>
> And, frankly, I don't see how you can put together a package that builds
> as per policy that builds using icc for main.
>
> Either your build target doesn't do what a build target should do,
ITYM s/build/clean/g
> or your build-depends are inaccurate, or something of that nature.
'Build-Depends' can contain virtual packages, and doesn't even have to
contain the compiler. One can simply
CC=icc dpkg-buildpackage -rfakeroot
without reflecting that fact in the Build-Depends field of debian/control
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Attachment:
signature.asc
Description: Digital signature