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: http://bugs.centos.org/view.php?id=4964 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". Akemi