[Ocfs2-users] Kernel independent OCFS2 packages for RHEL, Scientific Linux and CentOS

[Dag Wieers]

On Fri, 18 Jun 2010, Joel Becker wrote:

> On Fri, Jun 18, 2010 at 10:12:43AM +0200, Dag Wieers wrote:
>
>> I would like to announce a set of OCFS2 kABI-tracking kernel module
>> packages for RHEL5, Scientific Linux 5 and CentOS-5 and kernels. These
>> packages have been introduced into the ELRepo testing repository
>> (http://elrepo.org/).
>
> 	Thank you for taking an interest in ocfs2.  You've always been a
> great resource for folks working on el-like distributions and their
> limited package archives.  I have a couple of questions, if you don't
> mind.

You're welcome. And I don't mind, I might learn something new myself !


> 	First, do you have any provisions in your package dependencies
> to limit packages to certain update releases?  What I mean is, can one
> package be installed and used against EL5GA, EL5U1, ..., EL5U5?  Or do
> you have some mechanism to isolate a package to only a particular update
> release?  I bring this up because there are often ABI changes that are
> not detectable via modversions or any other automatic method we
> currently have.

Yes, thanks to the OCFS2 configure script I was aware about this. However 
since a single kmod module is provided for all installed kernels, there is 
no real mechanisme to prevent symlinks for a specific kernel.

At the moment we do expect at least one kernel equal or newer than 
2.6.18-92.el5 to be installed. But since weak-modules links based on 
modversions it will symlink those modules for older kernels too, if 
installed. This will effectively prevent the kmod to be installed on a 
system that is older than EL5.2, but it does not protect against the 
latter case.

Our current implementation is, in our opinion, balanced between what is 
desired and what is needed.

The only thing we could do is prevent the package to be installed if an 
older kernel is available, however we thought that was one bridge too far. 
The best solution is to make the mechanism stronger in such a way that 
this cannot happen, but we are only using what is available to us.

In fact there is a Driver Backport WorkGroup at the Linux Foundation lead 
by Jon Masers of Red Hat, and we follow his recommendations. If you think 
we can or should improve the infrastructure in future updates, I guess 
it's best to bring those issues up.


> 	On another note, I was wondering if you have any language
> mentioning that these are not the officially supported packages?  I want
> to be clear here.  We develop ocfs2 to be used as widely as possible,
> and we will never shortchange mainline or a packager like yourself when
> it comes to help on ocfs2-users and other community forums.  ocfs2 is
> something we're very proud of, and we back that to the best of our
> ability.  I'm just want to have a clear story for our customers.

Of course, I am sympathetic with corporate support issues, so please 
provide me with the specifics and rationale for any changes you desire
and I will discuss it with the rest of the team.


Thanks for your feedback !
-- 
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]