[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 03:08:34PM -0700, Joel Becker wrote:
>> On Fri, Jun 18, 2010 at 10:35:50PM +0200, Dag Wieers wrote:
>>> 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.
>>
>> 	Well, I don't have a specific answer right now.  I guess I'll
>> have to look at your packages and page directly to see what I can
>> suggest.
>
> 	Oh, my.  You provide 'ocfs2' and directly override the existing
> modules as delivered.  Am I correct that, should a person have our ocfs2
> package for 2.6.18-92.el5 installed and your kmod package, they will
> actually load your kmod module instead?  Is there any way to prevent
> this?

Well, our aim is to prevent that both packages are installed at the same 
time, because we don't want the user to not know for sure which package is 
being used. Unfortunately since the Oracle packages contain a 
kernel-version in the package name, we would have to Conflict or Obsolete 
every kernel released by Red Hat (and for each new released kernel, 
release our own kmod package), which obviously goes directly against our 
goals.

If you see a way around that, I am happy to implement that. But at the 
moment I don't see an easy way to do that, unless the official kernel 
module packages has a set of (kernel-agnostic) virtual provides, honestly 
I haven't checked that.

The reason for overriding the ocfs2 module the way we do is to ensure that 
if an ELRepo package is installed, it has the priority. This is the 
standardized way to do it with kmod packages, another kmod package would 
conflict on that file preventing a 'conflict'.

Beware though that the virtual provides of ocfs2 is just a mechanism to 
assist users to install ocfs2, there is no other reason.

I am open to improvements.
-- 
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]