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. -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
