[CentOS] Centos 6 Update?

Fri Apr 8 12:06:15 UTC 2011
Ned Slider <ned at unixmail.co.uk>

On 08/04/11 03:06, Lucian wrote:
> On Fri, Apr 8, 2011 at 1:00 AM, Jerry Franz<jfranz at freerun.com>  wrote:
>> On 04/07/2011 03:52 PM, Scott Silva wrote:
>>>
>>> The GPL says they must release source. It doesn't say they have to also
>>> release any magic spells they use to compile it.
>>>
>>
>> Actually, it *does*. If the code was released with missing 'magic fairy
>> dust' required to actually compile the GPL derived binaries they
>> release, they would be in violation of GPL2 section 3.
>>
>> You should read http://gpl-violations.org/faq/sourcecode-faq.html to
>> understand the implications of the GPL on source code release. You want
>> to read the sections on 'What are "scripts used to control
>> compilation"?' and 'What are "scripts used to control installation"?'
>
> Interesting. I wonder how would RedHat respond to this.


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.