FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-14-2011, 01:43 PM
Ben Hutchings
 
Default The future of m-a and dkms

On Mon, Feb 14, 2011 at 12:19:37PM +0100, Klaus Ethgen wrote:
> Hello,
>
> Am So den 13. Feb 2011 um 23:21 schrieb Patrick Matthäi:
> > 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.
>
> Well, dkms might be a good system for workstations, but on servers where
> you want to have reliable systems and security first you do not want
> dkms ever.

DKMS was developed by Dell originally to support servers (as they
did not sell any other systems running Linux until recently).

> With m-a it was and is possible to create nice debian packages for
> custom modules which can be installed on all systems getting all the
> same modules. With dkms that is not possible. More over you need to have
> a full gcc suite on all servers where you have custom modules. That is
> not acceptable.
[...]

This is not true. You can use 'dkms mkdeb' to build module packages
elsewhere.

Ben.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110214144323.GE28659@decadent.org.uk">http://lists.debian.org/20110214144323.GE28659@decadent.org.uk
 
Old 02-14-2011, 02:51 PM
The Fungi
 
Default The future of m-a and dkms

On Mon, Feb 14, 2011 at 08:29:38AM +0100, Hendrik Sattler wrote:
[...]
> 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?

At least for cases like the latter example, I find dh-make-perl a
lot better than letting CPAN run roughshod over my filesystem.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fungi@yuggoth.org); FINGER(fungi@yuggoth.org);
MUD(kinrui@katarsis.mudpy.org:6669); IRC(fungi@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110214155102.GB1293@yuggoth.org">http://lists.debian.org/20110214155102.GB1293@yuggoth.org
 
Old 02-14-2011, 02:57 PM
Marc Haber
 
Default The future of m-a and dkms

On Mon, 14 Feb 2011 00:12:48 +0100, Iustin Pop <iustin@debian.org>
wrote:
>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.

+1

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: E1Pp0nu-00070T-QW@swivel.zugschlus.de">http://lists.debian.org/E1Pp0nu-00070T-QW@swivel.zugschlus.de
 
Old 02-14-2011, 03:04 PM
Marc Haber
 
Default The future of m-a and dkms

On Mon, 14 Feb 2011 14:43:23 +0000, Ben Hutchings
<ben@decadent.org.uk> wrote:
>On Mon, Feb 14, 2011 at 12:19:37PM +0100, Klaus Ethgen wrote:
>> Am So den 13. Feb 2011 um 23:21 schrieb Patrick Matthäi:
>> > 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.
>>
>> Well, dkms might be a good system for workstations, but on servers where
>> you want to have reliable systems and security first you do not want
>> dkms ever.
>
>DKMS was developed by Dell originally to support servers (as they
>did not sell any other systems running Linux until recently).

We all know which strange ideas hardware vendors have with regard to
system administration.

>This is not true. You can use 'dkms mkdeb' to build module packages
>elsewhere.

That would be an acceptable workaround. Is there any way to prevent
dkms from trying to build modules for the currently running kernel
when module sources are installed (which is bound to fail in my build
chroot)?

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: E1Pp0us-0007CU-Fu@swivel.zugschlus.de">http://lists.debian.org/E1Pp0us-0007CU-Fu@swivel.zugschlus.de
 
Old 02-14-2011, 03:19 PM
Patrick Matthäi
 
Default The future of m-a and dkms

Am 14.02.2011 17:04, schrieb Marc Haber:

On Mon, 14 Feb 2011 14:43:23 +0000, Ben Hutchings
<ben@decadent.org.uk> wrote:

On Mon, Feb 14, 2011 at 12:19:37PM +0100, Klaus Ethgen wrote:

Am So den 13. Feb 2011 um 23:21 schrieb Patrick Matthäi:

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.


Well, dkms might be a good system for workstations, but on servers where
you want to have reliable systems and security first you do not want
dkms ever.


DKMS was developed by Dell originally to support servers (as they
did not sell any other systems running Linux until recently).


We all know which strange ideas hardware vendors have with regard to
system administration.


This is not true. You can use 'dkms mkdeb' to build module packages
elsewhere.


That would be an acceptable workaround. Is there any way to prevent
dkms from trying to build modules for the currently running kernel
when module sources are installed (which is bound to fail in my build
chroot)?


I don't think so, also the maintainer scripts execute the dkms build,
e.g. [0].


But this would be a serious goal for dkms and its implementation in the
maintainer scripts.



[0]:
http://svn.debian.org/wsvn/pkg-fglrx/fglrx-driver/trunk/debian/fglrx-modules-dkms.postinst



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D59562A.5060606@debian.org">http://lists.debian.org/4D59562A.5060606@debian.org
 
Old 02-14-2011, 03:30 PM
Vsevolod Velichko
 
Default The future of m-a and dkms

2011/2/14 Marc Haber <mh+debian-devel@zugschlus.de>:
> That would be an acceptable workaround. Is there any way to prevent
> dkms from trying to build modules for the currently running kernel
> when module sources are installed (which is bound to fail in my build
> chroot)?

As far as I can see, it wouldn't be a problem.
Patrick Matthäi just mentioned the very complicated way used in fglrx,
however I've once written debian package dealing with dkms [0] and the
following expression in .postinst was doing all the work:

if [ "$1" = "configure" ]; then
/usr/lib/dkms/common.postinst $PACKAGE_NAME $CVERSION "" $ARCH $2
/usr/sbin/update-initramfs -u
fi

As one can see in /usr/lib/dkms/common.postinst, it looks for kernels,
rebuilds everything and so on.
So I suppose it shouldn't be very hard work to make it behave the way you want.

[0] http://mentors.debian.net/debian/pool/main/h/hp-acpi-kill/

----
Best wishes and have a nice day,
Vsevolod Velichko


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTinZz6=dQYe-mw7JXxTsqesqc5ZXkqbkvon1BiLZ@mail.gmail.com">http://lists.debian.org/AANLkTinZz6=dQYe-mw7JXxTsqesqc5ZXkqbkvon1BiLZ@mail.gmail.com
 
Old 02-15-2011, 10:44 PM
Iustin Pop
 
Default The future of m-a and dkms

On Mon, Feb 14, 2011 at 02:43:23PM +0000, Ben Hutchings wrote:
> On Mon, Feb 14, 2011 at 12:19:37PM +0100, Klaus Ethgen wrote:
> > Hello,
> >
> > Am So den 13. Feb 2011 um 23:21 schrieb Patrick Matthäi:
> > > 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.
> >
> > Well, dkms might be a good system for workstations, but on servers where
> > you want to have reliable systems and security first you do not want
> > dkms ever.
>
> DKMS was developed by Dell originally to support servers (as they
> did not sell any other systems running Linux until recently).

That doesn't mean it's a good solution for servers, just that it can be
used on servers too. With bad results, see below.

> > With m-a it was and is possible to create nice debian packages for
> > custom modules which can be installed on all systems getting all the
> > same modules. With dkms that is not possible. More over you need to have
> > a full gcc suite on all servers where you have custom modules. That is
> > not acceptable.
> [...]
>
> This is not true. You can use 'dkms mkdeb' to build module packages
> elsewhere.

As others have said in this thread (and from my experience too), you
can't use dkms mkdeb to build and install separate packages for two
kernel versions but same module. That is because it uses only the
package name & version in the module paths, hence it doesn't support
nice upgrades.

iustin
 
Old 02-15-2011, 11:13 PM
Ben Hutchings
 
Default The future of m-a and dkms

On Wed, 2011-02-16 at 00:44 +0100, Iustin Pop wrote:
> On Mon, Feb 14, 2011 at 02:43:23PM +0000, Ben Hutchings wrote:
> > On Mon, Feb 14, 2011 at 12:19:37PM +0100, Klaus Ethgen wrote:
[...]
> > > With m-a it was and is possible to create nice debian packages for
> > > custom modules which can be installed on all systems getting all the
> > > same modules. With dkms that is not possible. More over you need to have
> > > a full gcc suite on all servers where you have custom modules. That is
> > > not acceptable.
> > [...]
> >
> > This is not true. You can use 'dkms mkdeb' to build module packages
> > elsewhere.
>
> As others have said in this thread (and from my experience too), you
> can't use dkms mkdeb to build and install separate packages for two
> kernel versions but same module. That is because it uses only the
> package name & version in the module paths, hence it doesn't support
> nice upgrades.

But you can build a single package that contains binaries for multiple
kernel versions.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
 
Old 02-16-2011, 07:58 AM
Josselin Mouette
 
Default The future of m-a and dkms

Le mercredi 16 février 2011 Ã* 00:13 +0000, Ben Hutchings a écrit :
> On Wed, 2011-02-16 at 00:44 +0100, Iustin Pop wrote:
> > As others have said in this thread (and from my experience too), you
> > can't use dkms mkdeb to build and install separate packages for two
> > kernel versions but same module. That is because it uses only the
> > package name & version in the module paths, hence it doesn't support
> > nice upgrades.
>
> But you can build a single package that contains binaries for multiple
> kernel versions.

Seriously, how useful is that?

--
.'`.
: :' : “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: 1297846722.29973.103.camel@meh">http://lists.debian.org/1297846722.29973.103.camel@meh
 
Old 02-19-2011, 07:00 AM
Marc Haber
 
Default The future of m-a and dkms

On Wed, 16 Feb 2011 00:13:07 +0000, Ben Hutchings
<ben@decadent.org.uk> wrote:
>On Wed, 2011-02-16 at 00:44 +0100, Iustin Pop wrote:
>> On Mon, Feb 14, 2011 at 02:43:23PM +0000, Ben Hutchings wrote:
>> > On Mon, Feb 14, 2011 at 12:19:37PM +0100, Klaus Ethgen wrote:
>[...]
>> > > With m-a it was and is possible to create nice debian packages for
>> > > custom modules which can be installed on all systems getting all the
>> > > same modules. With dkms that is not possible. More over you need to have
>> > > a full gcc suite on all servers where you have custom modules. That is
>> > > not acceptable.
>> > [...]
>> >
>> > This is not true. You can use 'dkms mkdeb' to build module packages
>> > elsewhere.
>>
>> As others have said in this thread (and from my experience too), you
>> can't use dkms mkdeb to build and install separate packages for two
>> kernel versions but same module. That is because it uses only the
>> package name & version in the module paths, hence it doesn't support
>> nice upgrades.
>
>But you can build a single package that contains binaries for multiple
>kernel versions.

So I'll have to build packages for each migration type that I want to
do and replace the modules _before_ the actual kernel update,
exchanging the modules for the currently running kernel in this
process?

This makes my toes curl. Please, Debian, don't force that on me.

Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: E1Pqhjm-00064d-1A@swivel.zugschlus.de">http://lists.debian.org/E1Pqhjm-00064d-1A@swivel.zugschlus.de
 

Thread Tools




All times are GMT. The time now is 02:41 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org