dkms 2.0.13.2 test release

[Panu Matilainen]

On Tue, 20 Feb 2007, Matt Domsch wrote:
> On Tue, Feb 20, 2007 at 01:01:20PM +0200, Panu Matilainen wrote:
>> On Tue, 20 Feb 2007, Matt Domsch wrote:
>>> - RHEL5 weak module recognition with new state installed-weak
>>> - autoinstaller recognizes installed-weak and doesn't rebuild
>
>> Nice!
>
> Thanks for the quick testing!
>
>
>> I started looking at this already but the recursive calls to
>> do_status() made by head spin :)
>
> I thank Gary for that particular bit of magic.  It flows, but took me
> a while to figure it out too, and that do_status_weak() needed to be
> outside of it to avoid getting caught in the recursion.
>
>> Couple of mostly cosmetical issues:
>>
>> 'dkms status' doesn't show installed-weak modules for all modules, just
>> one. 'dkms status -m <module>' on the other hand does show them:
>>
>> [root at localhost ~]# dkms status
>> thinkpad, 6.0, 2.6.18-8.el5, i686: installed
>> ciscovpn, 4.8.0, 2.6.18-8.el5, i686: installed
>> thinkpad, 6.0, 2.6.18-9.pm..el5, i686: installed-weak from 2.6.18-8.el5
>> [root at localhost ~]# dkms status -m ciscovpn
>> ciscovpn, 4.8.0, 2.6.18-8.el5, i686: installed
>> ciscovpn, 4.8.0, 2.6.18-9.pm..el5, i686: installed-weak from 2.6.18-8.el5
>
> That's going to take some work yet.  I had it working with a single
> module installed.  Need to track down why it's not with multiple...
>
>> dkms_autoinstaller doesn't try to build the package so it's just
>> cosmetical (and a bit misleading).
>
> That's probably because of the first problem.  If there's only one
> module in DKMS, it works.

dkms_autoinstaller does the right thing (as it uses "dkms status -m 
<module>"), no problem there. So "dkms status" not showing all modules for 
weak-updates is really a cosmetical issue, real functionality is not 
affected. While something that should of course be fixed eventually, it's 
hardly a critical problem.

>> Another purely cosmetics-issue is that dkms now assumes all
>> /lib/modules/<version> directories to contain weak-updates directory which
>> is not necessarily not true, causing a harmless "no such file or
>> directory" message to be spat out. Easily taken care of by /dev/null:
>
> Fixed.
>
>> A not so cosmetic thing is that dkms itself should call weak-modules after
>> installing and removing modules, something like the patch I sent earlier:
>> http://lists.us.dell.com/pipermail/dkms-devel/2007-February/000524.html.
>> Otherwise the links will only be created whenever new kernels are
>> installed. For example:
>> 1) kernel 2.6.18-1 running
>> 2) a new, kABI compatible version 2.6.18-2 becomes available, install it
>> 3) install something using dkms
>> 4) reboot to new kernel
>>
>> -> it'll needlessly rebuild the modules for 2.6.18-2 because dkms didn't
>> call weak-modules. Swap 2 and 3 in the above and this doesn't happen
>> because the kernel package installation takes care of that.
>
> Fixed.  Your patch needed to call /sbin/weak-modules outside the
> per-.ko loop (it's loop invariant if we pass the list of
> just-installed or just-removed modules to it rather than
> one-at-a-time).  But the idea was right.

Ok.

> Soon as I fix the first thing, I'll get another test release out.

Excellent :)

 	- Panu -