Kernel Module Packages - packaging - Fedora mailing-lists

18 Aug 2005


      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.