What's in a (CentOS) version number?

Posted Jun 11, 2014 23:26 UTC (Wed) by jspaleta (subscriber, #50639)
In reply to: What's in a (CentOS) version number? by khim
Parent article: What's in a (CentOS) version number?

well.. technically if a Vendor really was serious about only supporting RHEL already their installer would fail to work on CentOS already regardless of the release string. They could just as well check the rpmdb for the redhat-release package version _and_ they'd be using rpmdb package signatures to validate the package which provides the redhat-release file in question was unmodified and from signed RedHat signed binary rpm. Such logic in the installer would prevent wasting time supporting any CentOS installs...instead of just checking a very easily modified release string in the file system.

Or in other words.. just be very glad the installer devs were as lazy as they were in tasting the OS flavor, instead of actually validating the OS flavor.

-jef

What's in a (CentOS) version number?

Posted Jun 13, 2014 9:48 UTC (Fri) by jubal (subscriber, #67202) [Link]

Oh, I love the “I am altering the deal. Pray I don't alter it any further.” arguments.

What's in a (CentOS) version number?

Posted Jun 13, 2014 11:57 UTC (Fri) by dag- (guest, #30207) [Link] (3 responses)

And what about the more plausible case where a vendor wants to support both RHEL and compatible rebuilds ? The main reason why CentOS still offers /etc/redhat-release.

Why would CentOS risk breaking 3rd party software for a questionable change in version numbering ?

What's in a (CentOS) version number?

Posted Jun 13, 2014 16:30 UTC (Fri) by jspaleta (subscriber, #50639) [Link] (2 responses)

no idea. I'm just saying that 3rd party vendors aren't particularly serious about making sure the system isn't something else, if all the do is check an editable string sitting on the filesystem.

My personal opinion is that /etc/redhat-release should become an actual file instead of a symlink to centos-release, and /etc/redhat-release should be as compatible as the 3rd party ISV channel needs it to be to taste for RHEL binary compatibility. And then CentOS can do the more elaborate project naming stuff in /etc/centos-release.

There's no standing requirement that the files be the same content. It's just an historic anomaly because well 3rd party vendors starting hardcoding /etc/redhat-release as an important thing to taste so its become a defacto standard location to test OS version. Which if you think about it.. sucks..a filesystem with a vendor name in the filename to hold a string to tell you what vendor and version your system actually is. Its just..wrong. But we live with it.

For CentOS specifically, if the project still desires to be a binary compatible rebuild of RHEL, having /etc/redhat-release report the RHEL compatibility versioning that ISV installers expect, and /etc/centos-release supplying CentOS project specific versioning to aid local admins and contributors building content for the CentOS layercake...probably satisfies enough constraints to be a usable approach.

-jef

What's in a (CentOS) version number?

Posted Jun 14, 2014 11:07 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)

Why do you think 3rd party vendors suppport RHEL (and, sometimes, SLES) exclusively? Because they hate developers of all other distributions? Nope. They only support RHEL to save on support costs. As long as you don't explicitly say that you are using not RHEL but something else they could pretend that they don't know about that fact and will continue to support you.

Actually even if you'll say that you use CentOS they will not stop supporting you right away. More likely you'll hear something like “we don't support CentOS, try to reproduce on RHEL”. But if you'll show that package works on RHEL just fine but will continue to insist that they should “fix” to also support CentOS… what could they do? Eventually they will be forced to actually cite the piece of contract which lists supported distributions and cancel you support.

Note: if you think that they will go and fix their package because “it's so very easy” then you are wrong. In most cases bug will not be even shown to developers before it could be reproduced on RHEL! That's the whole point after all. It's possible that some developer will receive a world from his (or her) friends and will fix the package in question to be CentOS-compatible, but don't count on it as a rule. CentOS is tolerated till support of RHEL-conpatible packages is done by CentOS developers, if people will insist on theating it as anything but full RHEL clone it'll quickly lose even that thin “you don't say I don't hear” support it has.

P.S. And yes, separate redhat-release and centos-release look like a best solution to me.

What's in a (CentOS) version number?

Posted Jun 19, 2014 12:34 UTC (Thu) by farnz (subscriber, #17727) [Link]

On top of the reasons you're giving, note that it's not unknown for the 3rd party vendor to want to be able to punt problems in their dependencies back up to the enterprise Linux vendor. You may simply get an answer of "RHEL ticket opened - we'll push them on a fix, but you need to tell your support contact that you need the fix for #abcdefg ASAP."