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

Re: The future of m-a and dkms



Am 14.02.2011 00:12, schrieb Iustin Pop:
> On Sun, Feb 13, 2011 at 06:00:10PM -0500, Michael Gilbert wrote:
>> On Sun, 13 Feb 2011 23:52:22 +0100 Christoph Anton Mitterer wrote:
>>
>>> On Sun, 2011-02-13 at 23:21 +0100, Patrick Matthäi wrote:
>>>> since we have got a stable release with dkms now, I am asking myself, if
>>>> it is still necessary to support module-assistant.
>>>> dkms is IMHO the better system and maintaining two different systems for
>>>> kernel modules is a bit bloated.
>>> With dkms, can you also create packages of the modules?
>>>
>>> At least I found it always very useful, to create modules with m-a, or
>>> via make-kpkg, and provide them via local archives to all my Debian
>>> boxes. Can save quite some compilation time, and one doesn't need kernel
>>> header + build packages etc. on all nodes.
>>
>> Yes, there is the "mkdeb" command-line option, but I suppose that
>> doesn't get as much testing as it should.
> 
> With my sysadmin hat on, compilation on servers is a *very* big no-no,
> so if mkdeb doesn't work or if it doesn't provide nice modules, then m-a
> should stay in.

I find it useful, e.g. for several servers, running different kernel
versions.

> 
> 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.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatthaei@debian.org
        patrick@linux-dev.org

Comment:
Always if we think we are right,
we were maybe wrong.
*/

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: