How to force dkms_autoinstaller build and install even when status=installed-weak

[Fajar A. Nugraha]

Hi Matt,

Matt Domsch wrote:
> On Fri, May 25, 2007 at 01:10:49PM +0700, Fajar A. Nugraha wrote:
>   
>> So, for modules like qla2xxx, this means that when a kernel update
>> occurs, weak-modules will kick in, making dkms_autoinstaller refuse to
>> rebuild and install that particular version, but the kernel will not use
>> the weak-update.
>>
>>     
> Yeah, not really what you want.  Built-in should override
> weak-updates, as built-in *should* be newer than weak-updates, but
> there's no actual code in module-init-tools to check that.
>
>   
After giving some thoughts, I think that the best solution might be to
create a local version of module-init-tools that removes
/sbin/weak-modules altogether, and replace it with (perhaps) symlink to
/bin/true. The reasoning behind this is :

- As you mentioned, built-in should override weak-updates. At least
Redhat thinks so, although Suse folks don't.
- Built-in modules is included with kernel updates
- Non built-in kernel-module RPMs (the ones I need anyway) can be
converted to dkms modules
- The extra boot time required to build a kernel module is not issue

Which means there's no need for /sbin/weak-modules.
What do you think?


> Let me propose another solution.  You really want to get rid of the
> installed-weak module, and instead use one from extra/.  So you need
> to uninstall the one from installed-weak.  The easiest way is to:
>
> # dkms remove  -m $module -v $version --all
> # dkms add     -m $module -v $version
> # dkms build   -m $module -v $version -k $newkernelversion
> # dkms install -m $module -v $version -k $newkernelversion
>
> The alternative is to just have weak-modules remove the module so it's
> not considered installed-weak.  Then the dkms_autoinstaller will build
> it again and put it into extra/.
>
> # find /lib/modules -name qla2x00.ko | /sbin/weak-modules --remove-modules
> # /etc/init.d/dkms_autoinstaller start
>
> Not sure how to make that be automatic, or even if that's desired for the general case.  Probably not.
>
>   
That would be a problem. Especially since one dkms package can have more
than one kernel module, and AFAIK there's no way to get the list other
than parsing dkms.conf.

Regards,

Fajar