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 | [EMAIL PROTECTED] | VIM is http://tzafrir.org.il | | a Mutt's [EMAIL PROTECTED] | | best ICQ# 16849754 | | friend -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]