[CentOS] What happened to 6.1

Tue Nov 1 15:12:10 UTC 2011
Akemi Yagi <amyagi at gmail.com>

On Tue, Nov 1, 2011 at 3:02 AM, Peter Peltonen <peter.peltonen at gmail.com> wrote:
> Hi,
> On Tue, Nov 1, 2011 at 10:13 AM, Mathieu Baudier <mbaudier at argeo.org> wrote:
>>> If absolute 100% binary compatibility is not required, but admin-level compatibility and source-level compatibility with upstream EL is, Scientific Linux is covering that niche, and has their 6.1 out.

But then, CentOS does not give you "absolute 100% binary
compatibility" either. No clone distros would (see below).

> After installing a previous version of 3rd party SOGo RPM and
> reporting to the developers that the service wouldn't start after
> installation, I was informed that the RPM had been compiled on
> Scientific Linux 6.1 and because of binary incompatibility the RPM did
> not work under RHEL/CentOS. They recompiled on CentOS and the updated
> RPM installed/worked fine on my system.

This does not seem like a case of "binary incompatibility" as it is
referred to in this thread. For example, if a package is built against
a _specific_ version of another package in EL6.1 (let's say, a version
of kernel in 6.1), that package will have a compatibility issue with
EL6.0 (in this example, kernel in 6.0).

Binary compatibility is indeed a major thing for any clone distros and
is nearly impossible to achieve. This is because the build environment
is not disclosed by upstream (understandably) and rebuilders must do
some guessing or 'trial & error' work. Often times certain versions of
packages that were never released are required for the building.

Not all "binary incompatibility" will lead to real world consequences.
If, for example, upstream builds a package that links to bogus
libraries (that are never used by that package) and the rebuilt
package does not have those links, there should not be any problem
running it. But in rather rare cases, packages that were not built
correctly can result in failure in applications. For example:


As you can see, there is yet another item that makes rebuilding not
easy: build order. Package A-1.2.3 requires package B-4.5.6. So,
package B-4.5.6 must be built _before_ package A. We certainly cannot
blame the CentOS devs (nor the QA team!) for this particular instance.
It is simply extremely difficult to check every single case like that.

No clone distros, including CentOS and Scientific Linux, are perfect.
If someone asks which of the two has a better binary compatibility, I
would answer, "they are equally good".