On 07/01/2014 11:16 AM, Patrick J. LoPresti wrote:
On Tue, Jul 1, 2014 at 6:17 AM, Lamar Owen <lo...@pari.edu> wrote:
??? That is not at all what I got from his reply. What I got was that CERN
will still be committing resources, but instead of duplicating effort
they're joining up with the CentOS effort.
Whatever.
Well, apparently I understood Jarek's post correctly.
The relevant questions are: (1) Will SL's goal continue to
be creating a re-spin of Red Hat Enterprise and *not* CentOS, since
Red Hat's clear goal in acquiring CentOS is to create divergence
between the two;
It would be detrimental to their bottom line to do so, since so many
people are out there who could potentially blow the whistle on any such
divergence.
and (2) what mechanism(s) will SL use to achieve that
goal? (Specifically, will SL compare the git sources against actual
SRPMs obtained via subscription?)
If the SL developers want to reply, they will. I trust Connie and all
the rest are working on the situation, and I trust their judgement for
their project.
The *goal* of CentOS used to be binary compatibility, even if it was
never 100% achieved.
What matters is what they intended it to mean, which has never been 'bit
for bit identical.' What does 'binary compatibility' really mean? (I
take it to mean that all software compiled and linked for one will run
on the other; and that doesn't require the packages to be anywhere close
in terms of a binary compare; the CentOS test includes more than that.)
The following post from 2011 points to the info on how the CentOS
project has historically done the binary compatibility test:
http://lists.centos.org/pipermail/centos/2011-April/109483.html (the
actual script has been moved to vault; see
http://vault.centos.org/4.9/build/distro/tmverifyrpms for the actual
script, dated March 10, 2011).
Further, '100% binary compatibility' to me means that 100% of the
software built for one will run absolutely unmodified with identical
behavior on both systems (the binaries built on one are 100% compatible
with the other). Compatible doesn't mean and has never meant identical
at the byte for byte compare level.
...
No one yet in this thread has provided a public, no
login required, link to up-to-date sources for SLES 11.
Yes, you keep bringing this up as if it were an argument.
It's a valid counter-example. If the violation of not publicly
releasing source RPMS and tying subscription status with continued
access were so egregious then SuSE would have been sued into oblivion
long ago, and the absence of such suits makes it more difficult for the
argument to be made that Red Hat, which is making up-to-date sources
available, is violating where SuSE is not (which does not make
up-to-date sources available).
