Hello,
I have thought about rpm packages containing kernel modules independently of
the threads in this mailing list, which Matt Domsch was friendly enough to
pointed me at --- thanks, Matt. Maybe we can share some thoughts, and even
move our implementations a little closer together.
We've been looking at DKMS, and decided not to use it in favor of a purely rpm
based solution, so that the rpm database knows which modules belong to which
packages, etc. That's the same as with your proposals on
http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal.
One of the benefits of DKMS we saw was the ability to query which driver
packages were installed for a specific kernel. The same can be achieved by
checking which packages beside the kernel package itself install *.ko files
below /lib/modules/$(uname -r), so we'll achieve this feature by a script
that does that. Easy enough.
You seem to also prefix kernel module package names with ``kernel-module-'' to
make them easier to identify. Not really necessary I believe, especially
since they can as well be listed with --whatrequires.
We thought it useful to include a unique provider prefix in the package name
though, so that different vendors won't produce name clashes. Our plan was to
use the LANANA provider names registry (
http://www.lanana.org/) for that.
The driver name, driver version, and kernel release ($KERNELRELEASE) are also
stored differently in rpm tags: our build system likes to be able to freely
assign the package release number, so we don't store extra information there.
Rather, we put the driver version in the Name, and the kernel release in the
Version:
%define provider_prefix novell
%define driver_name foo
%define driver_version 1.1
%define flavor smp
%define kver %(rpm -q --qf '%{VERSION}-%{RELEASE}' kernel-source)
Name: %provider_prefix-%driver_name-%driver_version
Version: %(echo %kver-%flavor | tr - _)
Release: <arbitrary>
Requires: kernel-%flavor = %kver
The kernel version and release %kver is determined by the installed
kernel-source package.
The %flavor thing deserves some explanation: for each architecture, we have a
number of differerent kernel configurations which we call "flavors". The
config files for those flavors are found in arch/$ARCH/defconfig.$FLAVOR in
the SUSE kernel-source package, by the way. The kernel packages are called
kernel-$flavor, with version and release %kver. They additionally provide the
symbol kernel = %kver. There is some documentation at
http://www.suse.de/~agruen/kernel-doc/, in case anybody is interested.
Storing the driver version in the package name allows driver vendors to offer
multiple versions of the same driver for use with the same kernel. These
packages won't interfere with each other on updates, unless one of the
drivers Provides and Obsoletes another. We have learned with pain that
vendors sometimes drop features in drivers with higher versions, leading to
interesting customer situations. Because of that, we want kernel updates to
update driver versions only if explicitly requested.
One feature we allow is, we allow modules for multiple flavors (from the same
architecture) in the same kernel driver package. For example, a kernel driver
package could contain modules for 2.6.13-rc6-1-default, 2.6.13-rc6-1-smp, and
2.6.13-rc6-1-xen. It is very easy to build those modules, and most modules
are really small, so this reduces the number of packages we need to build,
and manage. In that case, the Version and Requires tags change to:
Version: %(echo %kver | tr - _)
Requires: kernel = %kver
Another interesting case is module package reuse: often modules from the
previous kernel can be reused with the new kernel after a kernel upgrade, in
case a new module package is not available. Dropping driver packages might
render systems unbootable (consider a raid adapter driver or similar).
It's quite easy to check if the modversions a module requires have changed. We
offer to reuse module packages if possible. When a user choses to reuse a
module package, we repackage the files in the old module package for the new
kernel, and move modules from /lib/modules/$old_kernel
to /lib/modules/$new_kernel. That way we can keep proper record in the rpm
database, and everything stays nicely manageable.
What I'm also missing in your proposals is mkinitrd calls: When modules that
are part of initrds get replaced, you also want to update it the initrds I
guess.
Regards,
Andreas.