Kernel modules packaged for dkms

[Matthias Saou]

Hi,

Regarding kernel modules, as many, I got tired of :
1) Packaging them as binary rpms, tracking new kernels to release new
packages (it's almost impossible to track Rawhide btw).
2) Endless discussions about what packaging method is the best, upgrade
paths, ugliness of versions inside names, common vs. kernel specific
bits etc. etc.

So I decided to go for the dkms approach to install 3rd party kernel
modules, and things got so much simpler. It's pretty obvious : If one
can issue a simple "make" to get a required module, why go through so
much complexity for rpm packages?

There are two possible discussions which can start here :

1) What do Fedora packagers think of dkms? Up to now, no kernel modules
packages using dkms have been released in Extras, nor in 3rd party
repositories AFAIK. Maybe there are some good reasons, in which case
I'm interested in knowing them.

2) If kernel modules packages using dkms are acceptable for Extras,
what guidelines should they follow? Here we'd need at least :
- A naming guideline, for which I'd suggest
"dkms-<modulename>" (Mandrake seems to be using that).
- Recommendations for the dkms calls in the scriplets. Do we build the
module for the current kernel on install (I do)? Do we run depmod on
install (I don't, but maybe I should)?

I'm possibly missing stuff. Anyway, here are some pointers :
http://svn.rpmforge.net/svn/trunk/rpms/dkms-tiacx/ (Extras candidate)
http://svn.rpmforge.net/svn/trunk/rpms/dkms-ipw3945/ (Needs fw/daemon)
http://svn.rpmforge.net/svn/trunk/rpms/madwifi/ (HAL license problem)
http://svn.rpmforge.net/svn/trunk/rpms/nvidia-x11-drv/ (definite NO!)

The last two are good examples of packages that provide both userland
tools and kernel modules, and show how splitting out sub-packages isn't
even required for this case.

Obviously, most 3rd party kernel modules aren't Extras candidates
because of licensing issues, but it would be nice nevertheless to have
some official Extras packaging guidelines for packages using dkms.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2726.fc6
Load : 2.72 2.84 1.53

[Jon Masters]

On Mon, 2006-10-09 at 15:13 +0200, Matthias Saou wrote:

>  1) What do Fedora packagers think of dkms? 
It requires building on the target to get the most out of it, and
therefore necessitates that you have those tools installed.

Having said that, I'd like to see DKMS being used on Fedora, just I
think we can't expect everyone to have working toolchains installed.

Jon.

P.S. I know it's not that clear-cut. You can always use some of DKMS
functionality anyway - it supports SuSE KMPs and in due course will
probably support the ABI tracking kmods in Fedora too...

-- 
Jon Masters              Cellphone: [phone]
Red Hat, Inc.                Email: jcm(a)redhat.com

[Rex Dieter]

Jon Masters wrote:
>  On Mon, 2006-10-09 at 15:13 +0200, Matthias Saou wrote:
>  
> > 1) What do Fedora packagers think of dkms?
>  
>  It requires building on the target to get the most out of it, and
>  therefore necessitates that you have those tools installed.
>  
>  Having said that, I'd like to see DKMS being used on Fedora, just I
>  think we can't expect everyone to have working toolchains installed. 
If folks will by using dkms-* rpms, then yes, given proper 'Requires: 
foo' magic, we can.  Unless you meant say something like "We can't 
expect everyone to like the necessity of having build toolchains just 
for dkms's..."

-- rex

[Matthias Saou]

Jon Masters wrote :

>  Having said that, I'd like to see DKMS being used on Fedora, just
> I
>  think we can't expect everyone to have working toolchains installed. 
Yeah, the packages pulled in by gcc (glibc-devel) and kernel-devel are
the main drawback. But, as much as I don't like installing anything
which isn't _really_ required on a system, since these 3rd party kernel
modules shouldn't be something everyone needs, and since the full kernel
sources aren't required nowadays (only the much smaller kernel-devel),
it's a "limited" drawback, that people wanting to install 3rd party
kernel modules should be willing to accept ;-)

Note that one can also use dkms to create rpm packages of the modules,
I haven't tried that, but it would add a layer of complexity to the
packaging and the build system. I definitely prefer keeping things as
simple as possible.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2726.fc6
Load : 1.60 1.40 1.24

[Nicolas Mailhot]

Le Lun 9 octobre 2006 15:31, Matthias Saou a écrit :

>  Note that one can also use dkms to create rpm packages of the
> modules,
>  I haven't tried that, 
I think that for most people who tried it:
1. dkms vs in-core module: dkms loses
2. dkms vs other form of external modules (kmdl or fedora-style) : dkms wins.

I know which form I took as base when I had to package ivtv 0.8 last
week-end.

Also dkms will increase the pressure on not applying fedora-specific
patches over the upstream kernel. Don't know if it's a good or a bad thing
(I know davej's opinion)

Regards,

-- 
Nicolas Mailhot

[Matthias Saou]

Nicolas Mailhot wrote :

>  I think that for most people who tried it:
>  1. dkms vs in-core module: dkms loses
>  2. dkms vs other form of external modules (kmdl or fedora-style) : dkms wins. 
I confirm that for my own case.

>  Also dkms will increase the pressure on not applying fedora-specific
>  patches over the upstream kernel. Don't know if it's a good or a bad thing
>  (I know davej's opinion) 
I'm not sure I understand the first sentence correctly :-/ If you meant
that it will reduce pressure to apply Fedora specific patches, it's
probably a good thing for the Fedora kernel maintainers, since a
parallel effort can be made to get the module(s) into the upstream
kernel, unless of course the Fedora kernel maintainers get swamped with
bug reports where kernels are tainted and/or running buggy modules
that don't come from the Fedora kernel...

But this discussion is also valid for the kmod packaging scheme anyway.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2726.fc6
Load : 1.43 1.46 1.20

[Paul Howarth]

Matthias Saou wrote:
>  Hi,
>  
>  Regarding kernel modules, as many, I got tired of :
>  1) Packaging them as binary rpms, tracking new kernels to release new
>  packages (it's almost impossible to track Rawhide btw).
>  2) Endless discussions about what packaging method is the best, upgrade
>  paths, ugliness of versions inside names, common vs. kernel specific
>  bits etc. etc.
>  
>  So I decided to go for the dkms approach to install 3rd party kernel
>  modules, and things got so much simpler. It's pretty obvious : If one
>  can issue a simple "make" to get a required module, why go through so
>  much complexity for rpm packages?
>  
>  There are two possible discussions which can start here :
>  
>  1) What do Fedora packagers think of dkms? Up to now, no kernel modules
>  packages using dkms have been released in Extras, nor in 3rd party
>  repositories AFAIK. Maybe there are some good reasons, in which case
>  I'm interested in knowing them. 
The ppp_mppe kernel module was successfully distributed as a dkms-based 
RPM package by the PPTP Client project before the module got included 
upstream in 2.6.15 (and is still used by distributions having older 
kernels).

http://pptpclient.sourceforge.net/yum/

Paul.

[Thorsten Leemhuis]

Matthias Saou schrieb:
>  Regarding kernel modules, as many, I got tired of :
>  1) Packaging them as binary rpms, tracking new kernels to release new
>  packages (it's almost impossible to track Rawhide btw). 
Well, the plan always was to be: Have support for kmod in the buildsys
and automate these things. Due to discussing kmod in the past again and
some other stuff it was never implemented. Now that we get more kmod in
Extras we should driver this forward again.

>  2) Endless discussions about what packaging method is the best,
> upgrade
>  paths, ugliness of versions inside names, common vs. kernel specific
>  bits etc. etc. 
Including this mail ;-)

>  So I decided to go for the dkms approach to install 3rd party kernel
>  modules, and things got so much simpler. It's pretty obvious : If one
>  can issue a simple "make" to get a required module, why go through so
>  much complexity for rpm packages? 
Well, with that argument we could stop our work on Fedora and RPM and
move over to Gentoo ;-)

Further: That argument  ("can issue a simple "make"") in parts also
holds true for dkms itself, too. In the beginning (2.4 days) dkms was a
nice idea because it easily allowed to compile modules for different
kernels. But exactly that function can be done by all 2.6 kernels
without dkms if they are shipped properly. Sure, dkms can do a lot more
these days, but I don't think we need most of it.

>  There are two possible discussions which can start here :
>  1) What do Fedora packagers think of dkms? 
We looked at it before we started the kmod effort and choose not to use
it. I don't see any reasons why this should have changed in between.

>  Up to now, no kernel modules
>  packages using dkms have been released in Extras, nor in 3rd party
>  repositories AFAIK. Maybe there are some good reasons, in which case
>  I'm interested in knowing them. 
Well, dkms kernel-modules are not directly forbidden (at least it's not
written down somewhere), but we choose to use kmod for kernel-module
packages -- so they are not allowed AFAICS.

And I don't think that we should change this as it helps people not much
if we put two or more competing standards in Fedora Core/Extras.

>  [...] 
I'm not in general against rebuilding modules on the users system -- but
it should be a option (e.g. for rawhide users), not the norm. I actually
implemented a small script once that did what most users want -- simply
rebuild the kmod-foo.srpm during boot up for the running kernel. I can
work on it again if people are interested. It did what we are interested
in in 5k -- dkms does a lot more what we don't need in 100k.

CU
thl

[Matthias Saou]

Thorsten Leemhuis wrote :

[...]
>  Well, dkms kernel-modules are not directly forbidden (at least
> it's not
>  written down somewhere), but we choose to use kmod for kernel-module
>  packages -- so they are not allowed AFAICS. 
Then I'd like the people who pushed the kmod scheme to be accepted to
try and get it to be 100% functional ASAP, as the whole build server
side, to get automated rebuilds for all newly released kernels is quite
far from being implemented (unless I'm mistaken).

>  And I don't think that we should change this as it helps people
> not much
>  if we put two or more competing standards in Fedora Core/Extras.
>  
>  > [...]
>  
>  I'm not in general against rebuilding modules on the users system -- but
>  it should be a option (e.g. for rawhide users), not the norm. I actually
>  implemented a small script once that did what most users want -- simply
>  rebuild the kmod-foo.srpm during boot up for the running kernel. I can
>  work on it again if people are interested. It did what we are interested
>  in in 5k -- dkms does a lot more what we don't need in 100k. 
But dkms is quite solid, handles errors in a user friendly way...
and "just works" overall while keeping things simple. Sure, the actual
modules aren't in the rpmdb, but are easily identifiable (dkms.conf). I
would really prefer to have all kernel modules cleanly installed with
rpm, believe me, but I'm simply not comfortable with any of the current
packaging schemes.

I packaged acx100 as acx-kmod a few months ago :
http://svn.rpmforge.net/svn/trunk/rpms/acx-kmod-common/
http://svn.rpmforge.net/svn/trunk/rpms/acx-kmod/

Honestly, it stopped me from wanting to package more kernel
modules... :-( Yesterday, I packaged the newer tiacx as dkms-tiacx :
http://svn.rpmforge.net/svn/trunk/rpms/dkms-tiacx/

...and it made me want to package _more_ kernel modules! The most
painful part for kmod is getting a build environment ready to rebuild
the module for all the different kernels. The whole complexity of the
spec file filled with macros and stuff generated from the kmodtool
script doesn't help either. I'm sure that if I had wrote it, I wouldn't
see it as being so complex... but I didn't.

Anyway, I think you answered my questions : dkms packages aren't what
Extras want, so no need to bother.
For the time being, I think I'll stick with dkms for my own 3rd party
kernel modules, and move to kmod only once the framework to make
packagers' life easier will be ready.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2726.fc6
Load : 0.22 0.38 0.70

[Panu Matilainen]

On Mon, 9 Oct 2006, Matthias Saou wrote:
>  Thorsten Leemhuis wrote :
>
>  [...]
> > Well, dkms kernel-modules are not directly forbidden (at least it's not
> > written down somewhere), but we choose to use kmod for kernel-module
> > packages -- so they are not allowed AFAICS.
>
>  Then I'd like the people who pushed the kmod scheme to be accepted to
>  try and get it to be 100% functional ASAP, as the whole build server
>  side, to get automated rebuilds for all newly released kernels is quite
>  far from being implemented (unless I'm mistaken). 
IIRC dkms was never *really* considered for the kernel module standard, 
everybody was too busy arguing over uname-r in name, how to handle 
debuginfo packages, what kind of macro magic to include, how many kernels 
to build for in buildsys, how to teach the kmod scheme to buildsys etc.

> > And I don't think that we should change this as it helps
> people not much
> > if we put two or more competing standards in Fedora Core/Extras.
> >
> >> [...]
> >
> > I'm not in general against rebuilding modules on the users system -- but
> > it should be a option (e.g. for rawhide users), not the norm. I actually
> > implemented a small script once that did what most users want -- simply
> > rebuild the kmod-foo.srpm during boot up for the running kernel. I can
> > work on it again if people are interested. It did what we are interested
> > in in 5k -- dkms does a lot more what we don't need in 100k.
>
>  But dkms is quite solid, handles errors in a user friendly way...
>  and "just works" overall while keeping things simple. Sure, the actual
>  modules aren't in the rpmdb, but are easily identifiable (dkms.conf). I
>  would really prefer to have all kernel modules cleanly installed with
>  rpm, believe me, but I'm simply not comfortable with any of the current
>  packaging schemes.
>
>  I packaged acx100 as acx-kmod a few months ago :
>  http://svn.rpmforge.net/svn/trunk/rpms/acx-kmod-common/
>  http://svn.rpmforge.net/svn/trunk/rpms/acx-kmod/
>
>  Honestly, it stopped me from wanting to package more kernel
>  modules... :-( Yesterday, I packaged the newer tiacx as dkms-tiacx :
>  http://svn.rpmforge.net/svn/trunk/rpms/dkms-tiacx/
>
>  ...and it made me want to package _more_ kernel modules! The most
>  painful part for kmod is getting a build environment ready to rebuild
>  the module for all the different kernels. The whole complexity of the
>  spec file filled with macros and stuff generated from the kmodtool
>  script doesn't help either. I'm sure that if I had wrote it, I wouldn't
>  see it as being so complex... but I didn't. 
Amen brother :) I've been intending to have a look at dkms for a long 
time, your post on the subject finally pushed me to actually do so. After 
converting a couple of kernel module packages (internal stuff at work) 
over to dkms, I'm simply loving it.

It's going to save me a helluva lot of time wasted on dealing with 
rebuilding kernel modules for this-and-that kernel, please the 
propellerheads running their own custom kernels and removes pretty much 
the impossibility of trying to deal with kernel module dependencies in 
some semi-correct way.

My only regret now is that I haven't looked at DKMS earlier :)

 	- Panu -

[Matthias Saou]

Panu Matilainen wrote :

>  Amen brother :) I've been intending to have a look at dkms for a
> long 
>  time, your post on the subject finally pushed me to actually do so. After 
>  converting a couple of kernel module packages (internal stuff at work) 
>  over to dkms, I'm simply loving it.
>  
>  It's going to save me a helluva lot of time wasted on dealing with 
>  rebuilding kernel modules for this-and-that kernel, please the 
>  propellerheads running their own custom kernels and removes pretty much 
>  the impossibility of trying to deal with kernel module dependencies in 
>  some semi-correct way. 
Well, the dkms approach is definitely best when it comes to enterprise
distributions (for which few or no kmod packages are available), custom
kernels or even rawhide.

>  My only regret now is that I haven't looked at DKMS earlier :)
Same here. And I definitely owe Gary Lerhaupt (the original author
it seems) an apology, as he contacted me back in early 2004 to explain
what dkms was and asked me if I'd be interested in making it available
on freshrpms. But I never took the time to look at it :-(

Maybe my original questions are still relevant, as if other people here
are interested in dkms kernel module packages for their own needs, we
might as well agree on a common naming scheme and some common
guidelines.
For now, I've been leaving the dkms enabled sources in the "main"
packages for projects that contain more than just kernel bits (nvidia,
madwifi), but still providing "dkms-<name> = V-R". Simple modules
I've
named "dkms-<name>" (dkms-tiacx, dkms-ipw3945).
As for the scriplets, I've just tried to add the rpm release to the
module version in order to make it easier to update a kernel module to
the same upstream version (i.e. a patched and fixed package), but I'm
not sure it's actually needed since I was still hitting other problems.
I'm still looking for the best solution to completely avoid corner
cases, make sure we never end up with a missing module, and handle all
possible updates correctly. This seems to work :

%post
# Add to DKMS registry
dkms add -m %{dkms_name} -v %{version}-%{release} -q --rpm_safe_upgrade
# Reuild and make available for the currenty running kernel
dkms build -m %{dkms_name} -v %{version}-%{release} -q || :
dkms install -m %{dkms_name} -v %{version}-%{release} -q --force || :

%preun
# Remove all versions from DKMS registry
dkms remove -m %{dkms_name} -v %{version}-%{release} -q --all \
    --rpm_safe_upgrade

But I'd like to avoid the --force, though.. I just can't seem to find
a way around it.

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.18-1.2726.fc6
Load : 0.31 0.26 0.26

[seth vidal]

On Tue, 2006-10-10 at 11:00 +0300, Panu Matilainen wrote:
>  On Mon, 9 Oct 2006, Matthias Saou wrote:
>  > Thorsten Leemhuis wrote :
>  >
>  > [...]
>  >> Well, dkms kernel-modules are not directly forbidden (at least it's not
>  >> written down somewhere), but we choose to use kmod for kernel-module
>  >> packages -- so they are not allowed AFAICS.
>  >
>  > Then I'd like the people who pushed the kmod scheme to be accepted to
>  > try and get it to be 100% functional ASAP, as the whole build server
>  > side, to get automated rebuilds for all newly released kernels is quite
>  > far from being implemented (unless I'm mistaken).
>  
>  IIRC dkms was never *really* considered for the kernel module standard, 
>  everybody was too busy arguing over uname-r in name, how to handle 
>  debuginfo packages, what kind of macro magic to include, how many kernels 
>  to build for in buildsys, how to teach the kmod scheme to buildsys etc.
>   
I think dkms is a good solution for sysadmins managing a bunch of
systems - but for our use situation it causes issues b/c we want people
to be able to install and use kernel modules w/o having to build them
and/or have all the build tools installed.

-sv

[Rex Dieter]

seth vidal wrote:

>  I think dkms is a good solution for sysadmins managing a bunch of
>  systems - but for our use situation it causes issues b/c we want people
>  to be able to install and use kernel modules w/o having to build them
>  and/or have all the build tools installed. 
You imply there are issues beyond simply the requirement of having build 
tools installed (and used).  What are they?

-- Rex

[seth vidal]

On Tue, 2006-10-10 at 07:39 -0500, Rex Dieter wrote:
>  seth vidal wrote:
>  
>  > I think dkms is a good solution for sysadmins managing a bunch of
>  > systems - but for our use situation it causes issues b/c we want people
>  > to be able to install and use kernel modules w/o having to build them
>  > and/or have all the build tools installed.
>  
>  You imply there are issues beyond simply the requirement of having build 
>  tools installed (and used).  What are they?
>   
I didn't mean to imply that.

That's all I was trying to say.

-sv

[Panu Matilainen]

On Tue, 10 Oct 2006, seth vidal wrote:

>  On Tue, 2006-10-10 at 11:00 +0300, Panu Matilainen wrote:
> > On Mon, 9 Oct 2006, Matthias Saou wrote:
> >> Thorsten Leemhuis wrote :
> >>
> >> [...]
> >>> Well, dkms kernel-modules are not directly forbidden (at least it's not
> >>> written down somewhere), but we choose to use kmod for kernel-module
> >>> packages -- so they are not allowed AFAICS.
> >>
> >> Then I'd like the people who pushed the kmod scheme to be accepted to
> >> try and get it to be 100% functional ASAP, as the whole build server
> >> side, to get automated rebuilds for all newly released kernels is quite
> >> far from being implemented (unless I'm mistaken).
> >
> > IIRC dkms was never *really* considered for the kernel module standard,
> > everybody was too busy arguing over uname-r in name, how to handle
> > debuginfo packages, what kind of macro magic to include, how many kernels
> > to build for in buildsys, how to teach the kmod scheme to buildsys etc.
> >
>
>  I think dkms is a good solution for sysadmins managing a bunch of
>  systems - but for our use situation it causes issues b/c we want people
>  to be able to install and use kernel modules w/o having to build them
>  and/or have all the build tools installed. 
Requiring clients to have build tools installed is a downside to dkms, 
yes, but me thinks it's really just a minor nuisance compared to the 
hideous mess of kernel module rpms.

 	- Panu -

[seth vidal]

On Tue, 2006-10-10 at 15:47 +0300, Panu Matilainen wrote:
>  On Tue, 10 Oct 2006, seth vidal wrote:
>  
>  > On Tue, 2006-10-10 at 11:00 +0300, Panu Matilainen wrote:
>  >> On Mon, 9 Oct 2006, Matthias Saou wrote:
>  >>> Thorsten Leemhuis wrote :
>  >>>
>  >>> [...]
>  >>>> Well, dkms kernel-modules are not directly forbidden (at least it's
> not
>  >>>> written down somewhere), but we choose to use kmod for kernel-module
>  >>>> packages -- so they are not allowed AFAICS.
>  >>>
>  >>> Then I'd like the people who pushed the kmod scheme to be accepted to
>  >>> try and get it to be 100% functional ASAP, as the whole build server
>  >>> side, to get automated rebuilds for all newly released kernels is quite
>  >>> far from being implemented (unless I'm mistaken).
>  >>
>  >> IIRC dkms was never *really* considered for the kernel module standard,
>  >> everybody was too busy arguing over uname-r in name, how to handle
>  >> debuginfo packages, what kind of macro magic to include, how many kernels
>  >> to build for in buildsys, how to teach the kmod scheme to buildsys etc.
>  >>
>  >
>  > I think dkms is a good solution for sysadmins managing a bunch of
>  > systems - but for our use situation it causes issues b/c we want people
>  > to be able to install and use kernel modules w/o having to build them
>  > and/or have all the build tools installed.
>  
>  Requiring clients to have build tools installed is a downside to dkms, 
>  yes, but me thinks it's really just a minor nuisance compared to the 
>  hideous mess of kernel module rpms.
>   
I disagree. I'd rather not force users on laptops to be exposed to that
level of pain.

-sv

[Matt Domsch]

On Tue, Oct 10, 2006 at 08:34:28AM -0400, seth vidal wrote:
>  I think dkms is a good solution for sysadmins managing a bunch of
>  systems - but for our use situation it causes issues b/c we want people
>  to be able to install and use kernel modules w/o having to build them
>  and/or have all the build tools installed. 
To be fair, DKMS doesn't strictly require the build tools and/or
kernel-$foo-devel be installed.  (The current Extras requirement that
kernel-devel be installed is, IMHO, a mistake, but FE Review strongly
asked for it).  It's designed to use kernel-devel and a toolchain if
present and no prebuilt module exists for your currently running
kernel.  Like the current FE kmod proposal, the build system *could*
rebuild *dkms drivers for the new kernel, and repackage them in the
*dkms package.  Exactly the same pain is needed for kmods; DKMS just
gives you an "out" if you've got a toolchain and kernel-devel
installed but your package provider hasn't (yet) respun their *dkms
package.

Thanks,
Matt

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

[Tom Callaway]

On Tue, 2006-10-10 at 11:00 +0300, Panu Matilainen wrote:

>  IIRC dkms was never *really* considered for the kernel module
> standard, 
>  everybody was too busy arguing over uname-r in name, how to handle 
>  debuginfo packages, what kind of macro magic to include, how many kernels 
>  to build for in buildsys, how to teach the kmod scheme to buildsys etc. 
FWIW, this is not quite correct. When I first started working on the
kernel module standard (back when I was the
one-man-singing-dancing-standards-generation-engine), I looked at DKMS.
(I even owned the package for a while in FE while Matt got his legal
ducks in a row). The reason I discarded it was this:

We can't expect end-users to have a build environment.

At the time, dkms without a build environment wasn't all that
interesting.

Now, IMHO, if dkms would run against a kernel ver-variant string passed
to it, and churn-churn-churn and spit out a set of kernel modules and a
filelist for rpm to use, then it would be an ideal replacement for a lot
of the kmod pain that we have today. Plus, it would do the building on
the buildsystem, which is where it should be.

(If dkms does this today, then super. Lets see an example spec.)

~spot
-- 
Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260

"We must not confuse dissent with disloyalty. We must remember always
that accusation is not proof and that conviction depends upon evidence
and due process of law. We will not walk in fear, one of another. We
will not be driven by fear into an age of unreason, if we dig deep in
our history and our doctrine, and remember that we are not descended
from fearful men -- not from men who feared to write, to speak, to
associate and to defend causes that were, for the moment, unpopular."
-- Edward R. Murrow, March 9, 1954

[Stephen John Smoogen]

On 10/9/06, Matthias Saou
<thias(a)spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net&gt;
wrote:
>  Hi,
>
>  Regarding kernel modules, as many, I got tired of :
>  1) Packaging them as binary rpms, tracking new kernels to release new
>  packages (it's almost impossible to track Rawhide btw).
>  2) Endless discussions about what packaging method is the best, upgrade
>  paths, ugliness of versions inside names, common vs. kernel specific
>  bits etc. etc.
>  
After dealing with various fedora systems where someone gets a kernel
update and things not working because an extra drvier wasnt ready.. I
am all for the dkms solution as a system administrator. Yes it takes
more stuff on a client system, but for my workloads.. it has worked
out a better solution for my fedora and enterprise systems.

-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Matt Domsch]

On Mon, Oct 09, 2006 at 03:13:43PM +0200, Matthias Saou wrote:
>  Hi,
>  
>  Regarding kernel modules, as many, I got tired of :
>  1) Packaging them as binary rpms, tracking new kernels to release new
>  packages (it's almost impossible to track Rawhide btw).
>  2) Endless discussions about what packaging method is the best, upgrade
>  paths, ugliness of versions inside names, common vs. kernel specific
>  bits etc. etc.
>  
>  So I decided to go for the dkms approach to install 3rd party kernel
>  modules, and things got so much simpler. It's pretty obvious : If one
>  can issue a simple "make" to get a required module, why go through so
>  much complexity for rpm packages?
>  
>  There are two possible discussions which can start here :
>  
>  1) What do Fedora packagers think of dkms? Up to now, no kernel modules
>  packages using dkms have been released in Extras, nor in 3rd party
>  repositories AFAIK. Maybe there are some good reasons, in which case
>  I'm interested in knowing them. 
The dell-software repo http://linux.dell.com/repo/software/
distributes openipmi, dcdbas, and dell_rbu for RHEL[34], SLES9, and
FC[34] because those distros didn't originally have them.  We've since
gotten those driver into kernel.org and therefore newer kernels and
distro versions, which has always been our goal all along - use DKMS
as a stop-gap until upstream and every distro kernel has a good-enough
version of each driver to not need to package them separately.

I'm glad for all the renewed interest, I had no idea how many people
were really packaging drivers using DKMS outside of Dell and our
immediate partners.  And yes, I owe Jon Masters some more time getting
DKMS fully up to speed with the work he's been doing with
kerneldrivers.org and KMPs.  I'm getting there, I promise!

Thanks,
Matt

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com