[CentOS-devel] CentOS 7 and release numbering

Sat Jun 21 21:48:22 UTC 2014
Johnny Hughes <johnny at centos.org>

On 06/21/2014 02:06 PM, Ned Slider wrote:
> On 21/06/14 17:56, Johnny Hughes wrote:
>> On 06/21/2014 08:49 AM, Ljubomir Ljubojevic wrote:
>>>>
>>> Just to emphasize, people want COMPATIBILITY with RHEL, that is why we
>>> use it. If there will be no PERCEIVED compatibility, people will start
>>> waling away from CentOS. As simple as that.
>> And the CentOS goal is full functional compatibility.
>>
> Johnny, I'm sorry to keep on at you, but this phrasing is another thing 
> that bothers me.
>
> For the last however many years (~10 years?) the CentOS Project has 
> always stated the goal is "100% binary compatibility". Now the change to 
> "full functional compatibility". It's not the same thing. Again, to me 
> all these things just send a signal of trying to dilute the direct 
> relationship that exists between CentOS and RHEL.
>
> Some may see this as nitpicking, but I'm concerned that the primary 
> stated goal for the last however many years has completely disappeared 
> from all official CentOS sites. Searching the Wiki now only finds 
> references to the phrase "100% binary compatibility" in archived release 
> notes and the main website makes absolutely no mention of RHEL nor the 
> relationship between the two distributions.
>
> Why would the CentOS Project stop using the phrase "100% binary 
> compatibility"? Have folks at Red Hat asked you not to use that phrase 
> any more? Do you still aim for "100% binary compatibility"? If not, 
> that's fine but lets get that fact out there so we all know where we 
> stand. If so, then lets say it as it's a really clear indication of what 
> CentOS aims to be - a 100% binary compatible clone of RHEL. Lets get it 
> on the front page of the website and the Wiki so folks know exactly what 
> they are buying into.
What does 100% binary compatible mean to you?

What it meant to us was this.  A proper ldd link to all the right
libraries, the same file list, size within 10%.  It was pointed out that
binary compatible means the same shasum of the items, which we never
have had and can not possibly obtain in a staged build system where
there are separate build repos.  So again, we are trying to be
completely honest on what we are checking for and what it means.

The script that we have been using to check for it is right here:

http://vault.centos.org/4.9/build/distro/tmverifyrpms

If we meet those things then we sign it can call it CentOS.  Same now as
before.  We are just trying to make sure we say what we have always been
doing in a correct way.  You can very easily see that CentOS isn't byte
for byte (binary)  compatible and we can never be.  Here is any example
of the differences in the newly compiled CentOS-7 and RHEL-7 libc-2.17.so:

[jhughes at jhughes glibc]$ cmp --verbose centos/lib64/libc-2.17.so
rhel/lib64/libc-2.17.so
    641 170 275
    642  30 167
    643 142 365
    644 207 307
    645 273  37
    646 247 261
    647 160 321
    648 151 225
    649 240 310
    650 126 353
    651 245 303
    652 314 142
    653 276 136
    654 261 250
    655 113 374
    656 177 231
    657 322 220
    658 312 114
    659  72 312
    660 113 302
1564865  66  63
1564868  60  71
2104765 235 153
2104766 246 151
2104767 351  16
2104768 345 235

================================

Here is the same test on 5.10:

[jhughes at jhughes glibc5]$ cmp --verbose centos/lib64/libc-2.5.so
rhel/lib64/libc-2.5.so
1192307  61  60
1192308  60  70
1192311  61  70

===============================

and on 6.5:

[jhughes at jhughes glibc6]$ cmp --verbose centos/lib64/libc-2.12.so
rhel/lib64/libc-2.12.so
    641 361 207
    642 241  20
    643 300 131
    644 127 275
    645 137 125
    646  16  52
    647 301 167
    648 101   6
    649 241 115
    650 127 317
    651 345 364
    652 337 313
    653 244 135
    654 122 265
    655 136  42
    656 160  53
    657 275 323
    658  47 232
    659 266  61
    660  56 304
1409431  62  60
1409432  61  65
1915241  45 352
1915242  40 137
1915243 224 160
1915244 234 257

===============================

So, we have never been binary (byte for byte) compatible ... instead we
wanted to be and checked for the things in the tmverifyrpms script above.

We just want to make sure we say what we are trying to do ... and the
same file lists, linking the same libraries, within 10% of the size is
it.  So thats what we want and that is "functionally" but not "byte for
byte" compatible.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20140621/b1496406/attachment-0007.sig>