User: Password:
|
|
Subscribe / Log in / New account

CentOS and Red Hat

CentOS and Red Hat

Posted Apr 3, 2014 18:49 UTC (Thu) by dag- (subscriber, #30207)
In reply to: CentOS and Red Hat by dowdle
Parent article: CentOS and Red Hat

Right. But if binary compatibility was a goal, it would be achievable today.

Yet, only "functional" compatibility is promised.


(Log in to post comments)

CentOS and Red Hat

Posted Apr 4, 2014 23:37 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

What is your perception of the difference between 100% binary compatibility and functional compatibility?

To me, they're synonomous, but "functional compatibility" is plainer English.

CentOS and Red Hat

Posted Apr 6, 2014 1:54 UTC (Sun) by egoforth (subscriber, #2351) [Link]

For me, "100% binary compatibility" means that I can take a RPM built on a RHEL system and know that I can yum install it on a CentOS system and it will "just work".
I'm not sure what "functional compatibility" means.

CentOS and Red Hat

Posted Apr 6, 2014 3:31 UTC (Sun) by raven667 (subscriber, #5198) [Link]

Until I see some evidence of intentional breakage I'm not going to presume it means anything different than what the CentOS team has been doing, it is better to judge people by _their_ actions than by _my_ fears.

CentOS and Red Hat

Posted Apr 8, 2014 15:48 UTC (Tue) by drag (subscriber, #31333) [Link]

> What is your perception of the difference between 100% binary compatibility and functional compatibility?

100% binary compatibility as a ideal state will never really be achievable, but it means that they are going to go all out bug for bug compatibility with as little regard as possible to improvements or bugs or user's concerns. So they, essentially, just slavishly try to match Redhat as close as possible.

Functional compatibility means that they are free to change things and improve things independent from Redhat as long as they try to make sure not to break compatibility with the mothership.

CentOS and Red Hat

Posted Apr 8, 2014 16:32 UTC (Tue) by dag- (subscriber, #30207) [Link]

I agree with your interpretation of both definitions.

But:

1. 100% binary compatibility would be possible today, if CentOS and Red Hat agreed that this is useful.

2. CentOS being free to change things and improve things without ensuring to break compatibility is an impossible task. If 100% compatibility is impossible because of differences in environment and tools (at the time of rebuilding) it surely is impossible to attempt the same while changing and improving things.

Besides, nobody would be in favor for CentOS to change/improve things and deviate from RHEL, it would defeat its purpose IMO.

In the light of things, I still find that change in wording very peculiar, and generally unwanted/unnecessary.

CentOS and Red Hat

Posted Apr 10, 2014 15:22 UTC (Thu) by giraffedata (subscriber, #1954) [Link]

Functional compatibility means that they are free to change things and improve things independent from Redhat as long as they try to make sure not to break compatibility with the mothership.

This is a circular definition. What compatibility is it they cannot break in order to have functional compatibility?

What compatibility is there to speak of besides 100% binary compatibility?

CentOS and Red Hat

Posted Apr 20, 2014 14:51 UTC (Sun) by hughesjr (guest, #29949) [Link]

Functional Compatibility is really what we have been trying to do all along. We just changed the wording to be more correct, nothing more.

By functional compatibility we mean bug for bug, link the same libraries, the same file lists in the package, etc. Basically, what we have been doing since the beginning and intend to continue to do in CentOS.

The real issue here is that we now understand that we will never have full binary compatibility since we build only on released CentOS packages and Red Hat is using a completely different staged build system. Red Hat sometimes builds a package into their staged build system multiple times between public releases, so they may do builds of packages against some library versions that are not released publicly. CentOS only builds against our released repositories. This means there always will be slight differences between CentOS and RHEL. As such, we are just trying to be more accurate in our description.

CentOS and Red Hat

Posted Apr 20, 2014 15:59 UTC (Sun) by giraffedata (subscriber, #1954) [Link]

By functional compatibility we mean bug for bug, link the same libraries, the same file lists in the package, etc.

...

The real issue here is that we now understand that we will never have full binary compatibility

Are you saying there are RPMs that work on RHEL but not CentOS? I.e. there are RPMs with which Red Hat is compatible but CentOS is not? If so, the functional compatibility is limited (because installing and running packages from RPMs is one of the significant functions of an OS), and you really should clarify that whenever you say "functional compatibility."

CentOS and Red Hat

Posted Apr 21, 2014 2:34 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

I think what they mean is that they compile the same code, but not inexactly the same way. If gcc-4.6-3 is different in CentOS and RHEL because RHEL was compiled with the -2 release (and recompiled because of some bug caught in QA) while CentOS was compiled with -1 since -2 never made it out the door, there's not enough time in the world to track down such differences. In reality, these differences are probably irrelevant, but you never know. If you do find an RPM which works on RHEL but not CentOS, you should file a bug.

CentOS and Red Hat

Posted Apr 22, 2014 14:14 UTC (Tue) by hughesjr (guest, #29949) [Link]

That is exactly what I am saying ... there are always some inherent differences.

However, if something runs on RHEL and not CentOS (and if that is for any other reason than the writer of the program specifically looks at something like /etc/redhat-release and runs only on RHEL and not CentOS on purpose) ... then this is a bug and we will figure out why it is not working and fix it.

So the answer is no, we are not saying anything about any changes in CentOS ... it is the same as it has been with respect to building RHEL sources. We are just telling you what kind of compatibility we have always provided.

Our goal is exactly what you want ... compile the exact sources, with the only changes in the core distribution being changes for branding and artwork.

CentOS and Red Hat

Posted Apr 22, 2014 15:57 UTC (Tue) by giraffedata (subscriber, #1954) [Link]

It sounds like there are people who think "full binary compatibility" means bit for bit identical, thus totally misunderstanding the word "compatibility." If so, it was a good idea for CentOS to stop using the term.

For anyone who is unclear on compatibility: it comes from latin meaning "ability to lie together" and refers to things that can coexist and work together.

We're already taking license with the term when we say two things with the same role are compatible with each other (for example, a classic Dell PC-clone computer being compatible with an IBM PC). In that case what it means is the two things are compatible with the same things.

CentOS and Red Hat

Posted Apr 22, 2014 16:20 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Well, it depends where you draw the line :) . Typical developers draw it at the linker-level (functions, data structures, call behavior, etc.), but there's a deeper one where you also ensure "compatibility" (I'd call it "binary identical" which reproducible build setups strive to attain) with those doing `sha1sum /usr/bin/ls` and expecting certain values for it. One user of the latter is SecureBoot which can (IIRC) have known-good hashes of binaries whitelisted (rather than public key signatures).


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds