[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The future of m-a and dkms

Zitat von Patrick Matthäi <pmatthaei@debian.org>:
I know that right now, when backporting stuff at work, we have to drop
the DKMS stuff and write our own packaging since DKMS doesn't play
nicely with multiple kernel versions, embedding the kernel *and* package
version in the final module version, etc. Things might have changed
recently, but last time I looked DKMS was only good for desktops, and
not as a reliable package-building method.

Of course, I might have wrong information, so clarifications welcome.

I think the disadvantage of dkms is, that apt will fail, if the module
couldn't be built for one of the "n" installed kernel versions, because
the module is not compatible {anymore} with the kernel version.
This process could be enhanced, by dropping an notify to the user, that
module "x" failed to buit on kernel version "y" and you might found more
information at "z". But you have got the same problems with m-a, just
you don't have to execute m-a by yourself.

Personally, this is the _main_ problem of DKMS. I am using e.g. virtualbox-ose but not often. I actually rather use "m-a -t a-i virtualbox-ose" than dkms because I do compile my own kernels that the virtualbox-ose modules often fail to compile with. I really do not want an aborted upgrade module or kernel upgrade because of that!

DKMS should be configurable upon installation when to enable automatic compilation of modules, meaning making automatic compilation totally optional (without having to manually remove most of the files from the package). It could even ship a m-a wrapper, doesn't it? (maybe only for the commonly used functionality).

Also, the idea of having files derived directly from distribution packages in /lib/modules/foo not visible to any standard package frontend seems strange and a bit like a step backwards. It's like having to install a package with "pear" because horde upgrade scripts once again requires a module that is not packaged in Debian (which was the case for Lenny and is also the case for Squeeze :-( ). Can those tools be integrated with e.g. aptitude?


Reply to: