[CentOS-devel] CentOS 7 and release numbering
Johnny Hughes
johnny at centos.org
Sat Jun 21 21:48:22 UTC 2014
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.sig>
More information about the CentOS-devel
mailing list