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