[CentOS] Centos 6 Update?

[Ian Murray]

> 
> As I seem to  have started this little subsection of the thread, please 
> let me give just  one small example to help clarify the situation as it 
> appears there is still  a lot of misunderstanding surrounding this issue.
> 
> Let's look at kernel  modules, kmod packages. They are built against one 
> specific kernel and then  weak link against all other kernels that are 
> kABI compatible. For example,  in CentOS 5.6,
> kmod-gfs is built against the 5.6 base release  kernel:
> 
> $ rpm -qlp  kmod-gfs-0.1.34-15.el5.centos.x86_64.rpm
> /lib/modules/2.6.18-238.el5
> /lib/modules/2.6.18-238.el5/extra
> /lib/modules/2.6.18-238.el5/extra/gfs
> /lib/modules/2.6.18-238.el5/extra/gfs/gfs.ko
> 
> but  when we compare that to the upstream package:
> 
> $ rpm -qlp  kmod-gfs-0.1.34-15.el5.x86_64.rpm
> /lib/modules/2.6.18-223.el5
> /lib/modules/2.6.18-223.el5/extra
> /lib/modules/2.6.18-223.el5/extra/gfs
> /lib/modules/2.6.18-223.el5/extra/gfs/gfs.ko
> 
> we  see it's been built against a 2.6.18-223.el5 kernel. This was a beta 
> kernel  and was never officially released so CentOS has no way to rebuild 
> their  package against this kernel. Hence, not 100% binary compatible.
> 
> There is  absolutely NO responsibility on Red Hat to release that kernel 
> that was part  of their build environment.
> 
> The package builds fine for CentOS against  the release kernel. In all 
> likelihood it will function identically to the  upstream packages, but 
> there is always a possibility that some weird  corner-case bug will 
> affect one package that doesn't affect the  other.
> 
> This situation with kmod packages is not at all uncommon as Red  Hat 
> invariably release kmods built against pre-release kernels and don't 
> rebuild them against the release kernel for GA. There are other examples 
> where packages might have been built against an unreleased version of 
> glibc or whatever but again these packages generally function fine, and 
> identically to upstream, but there is always a very small possibility 
> they might not function identically bug for bug. That's not to say the 
> RHEL package is any more right or wrong than the CentOS package, just 
> that they are different and hence by definition not 100% binary  compatible.
> 
> I hope that helps clarify some of the confusion surrounding  this issue.
> 

According to wikipedia....

"In computing, a computer that can run the same binary code intended to be run 
on another computer is said to be binary-compatible."

By this definition a well written emulator and the emulated machine are 
"binary-compatible", yet the build environments and other under the hood stuff 
can and are wildly different. So "different" does not mean it is not binary 
compatible.

Is CentOS working to a different definition? e.g. byte for byte identical (save 
for trademarks). Maybe that is the only way to reduce the risk of 
incompatibility, I don't know.