Tzafrir Cohen wrote: > Upon initial inspection of the dkms script, it seems to generate > deb packages whose name does not not include $KVERS . But I didn't test > it. > This is correct, because you don't want to have multiple DKMS packages installed to support many versions of the kernel module. The idea is that if you were to ship a binary kernel module in the package, you would be shipping the source with it. When the user were to install another kernel version, the source would be used to build a new binary kernel module.
This will not, by far, be the first package to install manage that are not contained within the package. You should see it just like the byte-compilation of elisp or python modules: when a new kernel/interpreter version is available, you need to compile/bytecompile the drivers/modules that are handled by dkms/python-{central,support}. The only thing that is different is that you need to ensure that the headers are installed for each of the kernel images. I would also much agree to install these files in a separate directory tree from /lib/modules/2.6.xx-y-zzz, so that no confusion arises. /var is not possible because it may not be mounted, but think /lib/modules.dkms for example. This requires simple changes to module-init-tools and initramfs-tools, but I think we can get something working simply and correctly. Earlier in this thread it was mentioned that since these compiled files are not managed by dpkg, that perhaps they should be stored in /var. This is already the case, /var/lib/dkms is where everything is stored at. It's copied over to /lib/modules/... If there is a worry about storing files in /lib/modules when they are copied, perhaps instead making this action a symlink would be better? -- Mario Limonciello *Dell | Linux Engineering* [EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature