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*
mario_limonciello@dell.com
Attachment:
signature.asc
Description: OpenPGP digital signature