DKMS (was Re: [ATrpms-devel] building lirc SRPM)

John Morris atrpms at butchwax.com
Sat May 22 07:56:57 CEST 2004


Hi, Gary!

I looked at DKMS last time Axel mentioned it.  I don't exactly
understand its purpose, though I didn't exhaustively read its
documentation.

As I told Axel last time, I'm not sure what is the significant
difference between these two commands is:

	dkms build -m megaraid2 -v 2.00.9 -k 2.4.21-4.ELsmp

and

	rpmbuild -ba megaraid2.spec --define "kernelver 2.4.21-4.ELsmp"

(where the .spec file defines the driver version).  I think the 
'dkms install,' 'dkms uninstall,' etc. commands have more obvious
equivalents in RPM-ese.  I think you argue something about having to
modify a specfile for each kernel-version/driver-version pair, but in my
experience, since many drivers come with accompanying non-driver files
(lirc is a good example; the ATrpms SRPM generates lirc, lirc-lib, and
lirc-lib-devel RPMs in addition to the actual kernel-module RPMs), each
new version of the software needs a new specfile anyway, and often with
new software versions, minor changes in the specfile aside from simple
version number changes are needed.

The only documentation I saw about the DKMS-RPM combo indicates that a
driver only gets built at the time of the 'rpm -i' command.  That
assumes that every machine that needs drivers not included in the kernel
RPM has a full build environment and a kernel-source RPM installed. 
That is a big assumption; many casual linux users don't select the
'development' option that installs compilers, etc. at RedHat
installation time, and many of these users probably won't ever need
those tools otherwise.  On my network, I have a few machines that are
intentionally stripped down both for the sake of security and for the
sake of running with minimal hardware requirements (eg. an old 486 with
a 300MB harddrive that only runs a kerberos server; it needs a FreeS/WAN
kernel module not in the stock RH kernel), and don't want to have to put
a full-blown build system on it just so I can install a new kernel
driver.

In summary, a kernel-module RPM that only 'Requires:' a specific 'kernel
= <kver>' is better than one that requires a properly-configured DKMS
and by extension a whole build system; and by my limited understanding,
my current method building arbitrary kernel-ver/driver-ver RPMs in the
ordinary way is equally simple to the DKMS method.  Please show me where
I'm wrong!  ;)

By the way, are you here in Austin's Dell facility?  Three years ago,
after Lucent bought our company, Agere, Inc., I tried to build the first
Linux compute cluster at Lucent from Dell hardware, but we couldn't get
the Dell saleswoman to go low enough, and Lucent made us go IBM.  We
were very disappointed!  I'm a big fan of Dell, a Texas company who
advocates Linux.

	John


On Fri, 2004-05-21 at 10:10, Gary Lerhaupt wrote:
> Rather than creating a rebuildable source RPM (which you later have to 
> manually rebuild as you move to different kernels), have you 
> considered instead using DKMS?  I know I must sound like just another 
> voice in the cacophony of packaging solutions, but the whole point of 
> DKMS was to address the shortfalls of RPMs handling of kernel 
> modules.  Mainly, Dell decided that RPM wasn't cutting it with our 
> customers for the handling of kernel modules, so we developed DKMS to 
> work with RPM such that RPM manages the version of the kernel module, 
> but DKMS handles which kernel versions its built and/or installed 
> upon.  You install the RPM once, and DKMS handles all the automatic 
> rebuilding from then on.
> 
> project: http://linux.dell.com/dkms
> paper: http://www.dell.com/downloads/global/power/1q04-ler.pdf
> 
> > Hi!  I'm busy modifying the lirc SRPM so that it is generally
> > recompilable against an arbitrary kernel-source package (in the same 
> way
> > I did the ivtv RPM).  There's something missing, though, that I'm 
> trying
> > to figure out:
> > 
> >    /usr/lib/atrpms/isnewi2c
> > 
> > This doesn't seem to be in the atrpms RPM, like I'd expect; where 
> can I
> > find a copy, or can you explain what it does?  In the lirc specfile,
> > this program determines whether the patch
> > 
> >    http://delvare.free.fr/i2c/lirc-CVS-i2c-2.8.0.patch
> > 
> > will be applied, but it seems this server is down, so there's no info
> > there.
> > 
> > Thank you!
> > 
> > 	John
> > 
> > 
> > _______________________________________________
> > atrpms-devel mailing list
> > atrpms-devel at atrpms.net
> > http://lists.atrpms.net/mailman/listinfo/atrpms-devel
> > 
> > 
> 
> 




More information about the atrpms-devel mailing list