Re: RFC: DKMS - Dynamic Kernel Module Support
On Thu, Sep 11, 2008 at 10:00:38AM +0200, David Paleino wrote:
> *Usability & Maintainability*
>
> 3) You don't need to know much about what you are doing in order to install a
> package that uses DKMS. If you look at the kqemu-source package in Ubuntu, the
> moment you install it, it builds modules for your running kernel. As soon as
> you install a new kernel, it will build modules for that kernel too. Any old
> kernels that you have, modules will be built as soon as you boot into the
> kernel.
> Compare this to module-assistant. You have to install kqemu-source, and then
> manually run module assistant for every single kernel you need modules for.
No on has answered that point. You didn't seem to read about the
options '-l' and '-k' of m-a.
Furthermore, m-a is part of the package management system, which is a
good thing. If my repository contains -modules packages, they will bo
automatically upgraded upon a new version of the module.
Building packages should be the norm. Having many files under /lib that
cannot be tracked by debsums is not something I like.
m-a handles building in a way I like (besides its defaulting to
full-screen mode).
Another issue: with rpm it is OK to have several packages of the same name
installed on the system. dpkg does not like this. Hence kernel modules
deb packages have the name $BASE-$KVERS (e.g: lirc-modules-2.6.26-1-686),
whereas rpm packages of kernel modules tend to encode $KVERS in the
Version field alone.
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.
--
Tzafrir Cohen | tzafrir@jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
tzafrir@cohens.org.il | | best
ICQ# 16849754 | | friend
Reply to: