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>