Ian Zimmerman <[EMAIL PROTECTED]> 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
