The future of m-a and dkms
 

Hello folk,

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.

I think there should be a decission for wheezy, how we should continue
with it.

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

The future of m-a and dkms
 

Patrick Matthäi <pmatthaei@debian.org> (13/02/2011):
> 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.
>
> I think there should be a decission for wheezy, how we should
> continue with it.

*MAYBE* you could put the maintainers in copy? (Eduard added.)

That said, I'm no longer interested in maintaining m-a (lack of time
is one thing, lack of interest is another, “upstream first� yet
another).

KiBi.

The future of m-a and dkms
 

Am 13.02.2011 23:39, schrieb Cyril Brulebois:
> That said, I'm no longer interested in maintaining m-a (lack of time
> is one thing, lack of interest is another, “upstream first� yet
> another).

Putting my fglrx maintainer hat on, I am also no longer interested in
supporting m-a, putting my server administrator job hat on, I am happy
that we have got dkms now.

dkms is more widley use (especially by commercial software products) and
so on we could reach a widley user- and developer-base.

I think it would be a nice release goal for wheezy, to get rid of m-a
and to migrate all related packages to dkms.

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

The future of m-a and dkms
 

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.


Cheers,
Chris.

The future of m-a and dkms
 

Am 13.02.2011 23:52, schrieb Christoph Anton Mitterer:
> 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.

You can still publish ready compiled module on the other nodes and I
don't think, that it is necessary to safe this little bit compile time
and extra space for the headers, to support m-a in the next releases.

Also with dkms this job could be done more automagic (especially with
new kernel versions).

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

The future of m-a and dkms
 

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.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110213180010.7463399d.michael.s.gilbert@gmail.co m">http://lists.debian.org/20110213180010.7463399d.michael.s.gilbert@gmail.co m

The future of m-a and dkms
 

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

regards,
iustin

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

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?


HS


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110214082938.6380382k10tcm9k4@v1539.ncsrv.de">ht tp://lists.debian.org/20110214082938.6380382k10tcm9k4@v1539.ncsrv.de

The future of m-a and dkms
 

Le lundi 14 février 2011 Ã* 00:12 +0100, Iustin Pop a écrit :
> 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.

Regardless, there should be a way to provide the modules without
installing a compiler on servers.

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

Worse, it is not a reliable method *at all*. When you have several
kernel versions installed, DKMS will only build the modules for one of
them, so if you reboot to another kernel, you get a brick.

--
.'`.
: :' : “You would need to ask a lawyer if you don't know
`. `' that a handshake of course makes a valid contract.�
`- -- J???rg Schilling


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1297675263.3044.212.camel@meh">http://lists.debian.org/1297675263.3044.212.camel@meh