RFC: packaging kernel modules
It does not seem that we have currently any conventions regarding the
packaging of kernel modules. I just tried the new alsadriver from
slink, and, for the same reason I could not use the packaged joystick
driver, this one too is useless to me.
Here are the main criticisms I have regarding how modules packaging is
currently done:
1) It appears that quite a number of drivers depend on some kernel
features (eg, for alsa, PCI support), which may be compiled in for the
default kernel, but which can be left out of a locally-compiled
kernel. This seem to be the cause for my problems, and I guess other
people may have the same problems.
2) These packages only provide compiled modules for some special
kernel version. Eg, alsa install its modules for 2.0.33; joystick
used to do it for 1 version I don't remember, and after a bug report,
finally included the driver for 2 kernel versions, which even did not
solve my problem, for the above-mentionned reason.
3) When for any reason using a kernel flavour (using the patch in
kernel-package), any pre-compiled module is also useless, as the
module dir is not the same (eg, I use a kernel with version
2.0.33-std, with modules under /lib/modules/2.0.33-std/; I cannot use
standard mechanims to reliably access alsa modules installed under
/lib/modules/2.0.33/)
kernel-package, which seem to be the tool to build a kernel the Right
Way on a Debian system, provides a framework to also build the
relevant modules from /usr/src/modules/, which can IMHO be used to
solve these problems.
I think the various modules should be primarily packaged in source
form, just as the kernel is, and installed under /usr/src/modules/.
>From these source packages, the binary packages would be generated for
the various binary kernel images shipped with Debian (presumably just
like the binary kernel images are), and users who locally recompile
their kernels will be able to recompile Debian-packaged modules from
Debian-packaged source.
>From current /var/lib/dpkg/available I additionnaly gathered:
* It seems the pcmcia modules use such an approach, with a
pcmcia-source package, and various pcmcia-modules-$(uname -r)
packages.
* The ultra, ibcs, ftape drivers also use the $(uname -r) string in
the package name, but do not provide a source package for
recompilation; most of them provide support for only one kernel
version.
Note that I had the idea of packaging alsa myself, but I wanted to
discuss these issues first...
What do others think about this problem ?
--
Yann Dirson <ydirson@mygale.org> | Stop making M$-Bill richer & richer,
isp-email: <ydirson@a2points.com> | support Debian GNU/Linux:
debian-email: <dirson@debian.org> | more powerful, more stable !
http://www.mygale.org/~ydirson/ | Check <http://www.debian.org/>
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: