[CentOS] Centos 6 Update?

[Johnny Hughes]

On 04/08/2011 07:25 AM, Ian Murray wrote:
> 
> 
>>
>> 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. 

The goal of the centos project is to produce an RPM that is exactly like
the upstream RPM in every way that is legally possible.

The checks we do look at libraries that binaries link to, size of the
packages and a list of the files the RPM installs.

We would like for all RPMS to be 100%, some (like the example above) are
not able to be linked against the same environment.

Upstream sometimes uses non released gcc's for compiling or they
sometimes build with non-released kernels or non released glibc's etc.
In those cases, we will do the best we can.

We do check these issues as part of the QA process and we do address
each one that we can.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/centos/attachments/20110410/dbae6dd7/attachment.sig>