Re: Kernel module package depending on kernel-headers.

[Tore Anderson <tore@linpro.no>]

Ian Zimmerman <itz@speakeasy.org> writes:

> Manoj> And you can set up your module postinst to install the module
> Manoj> in any directory you want -- /lib/modules/2.4/foo, for example,
> Manoj> and copy files at will.

There is no need to copy them. See below.

> Ian> But what is the point of having them in a package, then?
> 
> Manoj> Heh. I have 2.4.17 installed, and I install module_foo. Where
> Manoj> do the module files go?
> 
> Manoj> I now install 2.4.18. Now, either the module search path is
> Manoj> changed, or boom! no more module foo with new kernel.

Again, you are mistaken. Only parts of the search path is changed.

> Manoj> That is why the packaged module foo should copy files to 2.4.18
> 
> No.  That is why they should be _shipped_ by the module package in a
> more generic place to start with, and the generic place should be on
> the module search path.  Then you don't need to play postinst moving
> games, and you actually get the benefits of packaging (like, dpkg -L
> module_foo actually prints where the files are).

You are right. Modutils in Woody supports this, you can easily place
modules in /lib/modules/2.4/ - and insmod/modprobe/depmod will
happily use them, if equivalent modules doesn't exist in
/lib/modules/`uname -r`.

modprobe's manual page documents this:

       The idea is that modprobe will look first in the directory
       containing modules compiled for the current release of the
       kernel.  If the module is not found there,  modprobe  will
       look  in  the directory common to the kernel version (e.g.
       2.0, 2.2).  If the module is still  found,  modprobe  will
       look  in  the  directory  containing modules for a default
       release, and so on.

I think policy should reccomend third-party modules to be installed
in the the directory common for all kernels with the same minor
release.

-- 
Tore Anderson