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

CentOS and Red Hat

CentOS and Red Hat

Posted Apr 3, 2014 12:38 UTC (Thu) by dag- (subscriber, #30207)
Parent article: CentOS and Red Hat

The elephant in the room (now that CentOS has joined Red Hat) is why even do the (great) effort in rebuilding CentOS in a different environment if it becomes possible to have CentOS release identical builds as to what ships in RHEL ?

One of the strengths and attractiveness of CentOS always was that CentOS strived to be 100% compatible to what Red Hat shipped. Obviously 100% compatibility was not possible before, but now it can be. Yet that goal seems to have disappeared.

The wiki (http://wiki.centos.org/FAQ/General?action=diff&rev2=9...) used to state:

> CentOS conforms fully with the upstream vendors redistribution policies and aims to be 100% binary compatible

but since 2014-01-07 only says:

> CentOS conforms fully with the upstream vendors redistribution policies and aims to be functionally compatible with the upstream product.

And from Red Hat's FAQ (http://community.redhat.com/centos-faq/#_centos_and_red_h...):

> Only Red Hat produces, validates, and distributes authenticated Red Hat Enterprise Linux binary packages with certified and tested ISV and IHV compatibility.

So while I assume this is the reason to have a firewall between the CentOS project and the RHEL product, why this change of heart ?


(Log in to post comments)

CentOS and Red Hat

Posted Apr 3, 2014 12:42 UTC (Thu) by dag- (subscriber, #30207) [Link]

Let me clarify that I agree that for the CentOS project there are a lot of benefits to join Red Hat. Just the fact that the CentOS developers can work fulltime on CentOS and they can contact Red Hat people internally, is a massive win for them and for the project.

That's not at dispute.

CentOS and Red Hat

Posted Apr 3, 2014 16:11 UTC (Thu) by dowdle (subscriber, #659) [Link]

Dag, I think it was a change in wording but not really a change in the goals. Why the change in wording? Well to make those lawyers who speak their own language happy.

CentOS and Red Hat

Posted Apr 3, 2014 18:45 UTC (Thu) by NightMonkey (subscriber, #23051) [Link]

Hrm. Who cares about making RedHat lawyers happy? Oh, right. CentOS does now. It didn't before. This is where it starts.

"Wording" matters.

CentOS and Red Hat

Posted Apr 3, 2014 18:49 UTC (Thu) by dag- (subscriber, #30207) [Link]

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

Yet, only "functional" compatibility is promised.

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).

CentOS and Red Hat

Posted Apr 4, 2014 2:29 UTC (Fri) by salimma (subscriber, #34460) [Link]

One of the strengths and attractiveness of CentOS always was that CentOS strived to be 100% compatible to what Red Hat shipped. Obviously 100% compatibility was not possible before, but now it can be. Yet that goal seems to have disappeared.
A likely explanation is that core (with its own build system) is the part that is 100% binary compatible with RHEL, while the different SIGs, by definition, are not, as they build on top of CentOS and in some cases even replace core components such as the kernel (e.g. for Xen support)

CentOS and Red Hat

Posted Apr 4, 2014 12:07 UTC (Fri) by dag- (subscriber, #30207) [Link]

> A likely explanation is that core (with its own build system) is the part that is 100% binary compatible with RHEL, while the different SIGs, by definition, are not, as they build on top of CentOS and in some cases even replace core components such as the kernel (e.g. for Xen support)

If that would be the case, replacing it with "functionally compatible" doesn't improve anything as it also applies only to the "core". So it does not explain the change.

Also the effort to rebuild CentOS core with the goal to make it as compatible as possible to RHEL, is a wasted effort if only the builds would be made identical to RHEL, rather than a reverse engineered effort with different tools, a different process and a different environment.


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