Bug#29474: marked as done (binaries compiled on slink don't run anywhere else )
Your message dated Sun, 7 Feb 1999 19:54:09 -0800
with message-id <v04104418b2decee150a6@[206.163.71.146]>
and subject line Closing fixed bugs.
has caused the attached bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I'm
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Ian Jackson
(administrator, Debian bugs database)
Received: (at submit) by bugs.debian.org; 15 Nov 1998 10:42:20 +0000
Received: (qmail 7915 invoked from network); 15 Nov 1998 10:42:19 -0000
Received: from earth.laney.edu (root@204.30.23.8)
by master.debian.org with SMTP; 15 Nov 1998 10:42:19 -0000
Received: from earth.laney.edu (jim@localhost [127.0.0.1])
by earth.laney.edu (8.8.8/8.8.8/Debian/GNU) with ESMTP id CAA22613;
Sun, 15 Nov 1998 02:42:05 -0800
Message-Id: <199811151042.CAA22613@earth.laney.edu>
To: "Marcelo E. Magallon" <mmagallo@efis.ucr.ac.cr>
cc: submit@bugs.debian.org, debian-devel@lists.debian.org, jim@earth.laney.edu
Subject: Re: binaries compiled on slink don't run anywhere else
In-reply-to: Your message of "Sat, 14 Nov 1998 11:50:00 CST."
<19981114115000.A11518@efis.ucr.ac.cr>
Date: Sun, 15 Nov 1998 02:42:04 -0800
From: jim@laney.edu
I really don't understand how lack of binary compatibility between
distributions can be considered anything close to critical... In my
opinion, it's very, very far from even important. I doubt whether
binary incompatibility with anything but slink has anything whatsoever
to do with the slightest problem.
I am trimming the distribution list because replies to this note and
also the original should probably not go to submit@bugs.debian.org.
I have been around long enough to know that two compiles of the same
library with only one or two option changes can mean binary incompatibility.
Header files change, and so do kernel versions as well as compilers. Any
one of these can result in total incompatibility between binaries. Because
debian has chosen to take on the maintainance of the compilers and libs
and to make most or all of the decisions about their compiling, the only
route to full binary compatibility is to copy what the other dist does,
i.e., to have the exact same kernel options when compiling the kernel, then
the exact same library config when compiling the library, the same header
files and etc.
The question becomes: do you want binary compatibility or do you want free
progress to real improvements? I contend that at approximately the level of
the operating system and the base libraries, these two ideas are mutually
exclusive, or nearly so.
If you want something to run on a different operating system, you must
ask yourself: do you have the source code? If the answer is yes, then I'm
sorry, bzzt, wrong, you cannot expect binaries to run there if progress is
desired at the operating system level. Redhat is progressing in their own
direction and so either make decisions about lib and kernel compile-time
options accordingly, or else accept what H. J. Lu creates. My personal
opinion on libs, compilers and kernels, is that any linux user should be
able to get any source code from the definitive source and compile it
themselves.
One thing H. J. Lu does is he tries to help get the libs, compilers
and kernels working together by working on the compiler itself so that it
can compile the kernel and the libs. To do this, he has to use "snapshots"
of gcc and/or egcs (unreleased versions) and send compiler patches to the
team working on the compiler. For this reason, there is a (weak) barrier
whose effect is to try to prevent others from compiling the libs. This also
helps to get a compiler that can eventually compile the libs, but because
the compiler has to be modified to successfully compile the libs, it's
usually behind, there's usually a new lib whose binaries are released but
sources can only be compiled by compiler snapshots, which the compiler
team are usually reluctant to release since it's not stable yet. However
the compiler snapshots are GPLed therefore they can't legally prevent their
release. Somewhat messy... but Mr. Lu is trying his best to provide service
to linux.
Hence, binary compatibility is very difficult to achieve, and probably not
worth the effort if the goal is to progress at the systemic level. I
therefore contend that source code compatibility, being the mainstay of
open-source, is quite sufficient. If one has the source, one can compile
it themselves and should -definitely- do so, or risk subtle breakages or full
incompatibility.
In conclusion, I contend that this bug which has been made "critical" is
in no way critical at all. It is not even important, or close to it because
anyone who wants to have a binary on any given system is absolutely free
to compile it there, themselves. Let's find real bugs, please, and get on
with what IS important: the release of 2.1.
-Jim,
who has no vote here and can't keep his mouth shut when important things
come up :)
Reply to: