[ATrpms-devel] Re: DKMS

[Gary Lerhaupt]

On Mon, 2004-05-24 at 20:25, John Morris wrote:
> 
> In your message to Jarod, you wrote that DKMS-ified kernel module RPMs,
> as shipped to customers, include binary modules.  Is that true?  Is it
> true, then, that one could build an RPM that packages kernel modules for
> all the common 'flavors' of RedHat kernels, so that it could be
> installed on a machine without the dev tools?  How is that done? 

Yes, the DKMS-enabled RPMs we give to customers also include binary
modules.  In our case, we just precompile for 2.4.21-4.EL and its
variants, but you could
certainly include prebuilts for whatever kernels you'd like.  On your
build machine, you'd do:

$ dkms build -m $module -v $version -k 2.4.21-15.EL
$ dkms build -m $module -v $version -k 2.4.21-15.ELsmp
$ dkms build -m $module -v $version -k 2.4.21-15.ELhugemem
$ dkms mktarball -m $module -v $version 

Then you take the tarball that it creates, place it in your RPM SOURCES
and from your rpm, you'd call:

%post
dkms ldtarball --archive pre-builts.tgz

>  It
> seems strange, since the kernel modules must be built outside the
> rpmbuild process, and then put into the .src.rpm as source files.  

Agreed.  DKMS-enabled RPMs are not the norm as the binary RPM you create
includes not only the source of your module but also prebuilt binaries. 
Of course, to the end user, they just want it to work when they do rpm
-ivh.  And to remove the expertise needed for the customer to learn the
rpmbuild process and then install rebuilt RPMs is an advantage.

> The
> advantage of this is not only that it saves customers lots of $$$ to not
> have DKMS recompile the drivers for their system, but also that they
> don't have to keep a whole dev environment around on every single system
> just so they can install new kernel modules.  *That* would convince me
> to consider making the switch to DKMS.  

So is this convincing?  Another thing along the same lines is the
possibility for system admins to use DKMS to just have one machine with
sources so they can build modules as needed.  They can then use
mktarball and ldtarball as systems management tools to deploy these
across their enterprise.

> It would be even more
> interesting if there were a 'mkrpm' analog to 'mktarball' that could
> pack up DKMS kernel-module SRPM/binary RPMs, and include binary versions
> of the particular modules needed on one's network

I considered a mkrpm but there was a lot of complexity in properly
solving that.  Besides, to remain germane to the concept of DKMS
managing kernel modules, such an RPM would itself need to use DKMS
commands internally, requiring the end system to have DKMS installed. 
If you know DKMS has to be installed on the end user system, you might
as well just use DKMS prebuilt binary tarballs.

BTW, we have a dkms-devel at lists.us.dell.com mailing list.

Gary