[elrepo-devel] a few comment about elrepo's packages

[Phil Perry]

Farkas Levente wrote:
> On 08/29/2009 12:01 PM, Alan Bartlett wrote:
>> On 29/08/2009, Phil Perry<phil at elrepo.org>  wrote:
>>
>> <snip>
>>
>>>   2. Blacklisting
>>>
>>>   We provide a standardised mechanism within kmodtool for blacklisting
>>>   modules where needed. Alan would be able to give you an example of a
>>>   modules that requires this, but I believe some of the network controller
>>>   driver modules do.
>> When either the kmod-r8101 or the kmod-r8168 package is installed, the
>> Red Hat distributed 8169 module is blacklisted.
>>
>> The requirement, to blacklist any existing 8169 module before a 8101
>> or 8168 module is loaded, is specified in the Realtek documentation.
> 
> anyway it's a good question how to handle future kernel which include 
> elrepo's kmod? eg. when 5.4 comes out what happened with xfs, kvm and 
> fuse kmod which will included in the upstream kernel?
> solution:
> 1. everybody have to remove by hand old kmods before reboot with the new 
> kernel.
> 2. as we can't expect that upstream kernel will obsolete old kmods we 
> can somehow check the new kernel's kmods.
> 

Indeed, very valid points. Dag and I were discussing this the other day.

Currently we ship all kmods with an override conf file in 
/etc/depmod.d/{foo}.conf so by default it will be our module that is 
used rather than the new kernel module.

I'm of the opinion that we shouldn't attempt to micro-manage people's 
systems for them. If they have installed an updated driver from elrepo 
then they need to take responsibility for that and keep it updated as 
necessary and/or remove it once it becomes obsoleted upstream. We WILL 
make that information available to users at things develop, so when 
el5.4 is released, if we decide to deprecate kmod-fuse or kmod-xfs etc 
in favour of the kernel driver then we will announce that to the ML with 
a recommendation that users uninstall the kmod package.

However, in some circumstances there may be reasons where continuing to 
provide a kmod package may provide benefits so it's a case by case 
situation.

> anybody has any tipp for this? eg. in my case i wouldn't like to remove 
> by hand these modules on 400 servers:-( and the same is true for 8101 
> and 8168 since 5.3's 8169 include the driver for these models.
> 

Indeed, I don't know of an easy solution given what we have to work 
with. Obviously as you identify we don't control the upstream kernel so 
are unable to obsolete kernel module packages.

Personally, having been badly bitten by r8169 in 5.2, I'm reluctant to 
try it again so am very happy to stick with kmod-r8168 that has always 
worked flawlessly for me. The distro r8169 just did too many weird 
things that took me months to even track down and realise were being 
caused by a buggy nic driver.