ATrpms' kernel modules (kmdls)

[Dan]

Axel Thimm wrote:
> On Wed, Apr 26, 2006 at 03:11:02PM +0200, Tim Lauridsen wrote:
>   
>> Axel Thimm wrote:
>> I not a kernel module packager, so i can't comment on the methology, but 
>> from a user perspective the most important feature is automatic updating 
>> of kernel-modules when new versions of the kernel is installed by yum, 
>> this is working great with the madwifi,ntfs,nvidia drivers in the livna  
>> fc5 repository. if kmdls can be used in the same way, then fine with me 
>> for a users perspective.
>>     
>
> There is a general issue with kernel modules and upgrading, not only
> affecting the way ATrpms does it, but far more general. In a nutshell
> you have a two-dimensional versioning which cannot be put into an
> mathematically ordered relationship, no matter what you try (in fact
> it can be proven mathematically for |Rx|R ;)
>
> So for rpm's sake you need to neutralize one versioning and that leads
> to the ugly-uname-r-in-package-name, or you break certain scenarios.
>
> That OTOH makes yum/smart/apt properly upgrade within the kernel
> (e.g. new kernel module for the same kernel), but not across
> kernels. apt does have some special support to do that and yum and
> smart could be taught, too.
>   
Livna used to have the uname-r-in-package-name scenario, which worked 
well because a kernel module for 2 different kernels was seen by yum as 
two different packages, and this is desired functionality. They changed 
now so that the package name is simply "kmod-ntfs" or similar, and thus 
yum is now updating it when you get one for a new kernel, leaving the 
old kernel without a module :(. I agree, if yum and smart were improved 
to handle the two-dimensional versioning, that would make everything 
much simpler.
[snip]
-Dan