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 <[EMAIL PROTECTED]> | Stop making M$-Bill richer & richer, isp-email: <[EMAIL PROTECTED]> | support Debian GNU/Linux: debian-email: <[EMAIL PROTECTED]> | more powerful, more stable ! http://www.mygale.org/~ydirson/ | Check <http://www.debian.org/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]