This allows RPM to generate Provides:kmod(foo.ko) statements for every
module shipped in the package. That in turn allows packages to put
requires on specific modules and not worry about which package they are
located in.
Pretty grody, but it seems to be working... it has to happen after
module signing (obviously) and after find-debuginfo.sh runs as well, so
tacking it onto the end seems sensible, and then just fixing up the file
lists as we go. Provides a nice tidy savings to the disk footprint:
kyle@dreadnought:~% for i in kernel-core-3.15.0-0.rc3.git4.1.fc21.x86_64.rpm \
kernel-core-3.15.0-0.rc3.git4.1.fc21.x86_64.rpm.1; do \
rpm -qip $i | grep '^Size'; done
Size : 43011603
Size : 81106737
kmod has handed .xz and .gz modules for a long time now, and can cope.
I was thinking we might also %ghost the .ko, and have a %post install
script that un-xz the modules in /proc/modules, but none of them are big
enough for that to be worthwhile I think (maybe XFS, but I doubt it.)
--Kyle
Without that, we wind up with kernel, kernel-core, kernel-drivers,
kernel-debug-core, and kernel-debug-drivers. So there's no kernel-debug
meta-package to take the place of the previously created kernel-debug package.
Not sure how I missed that.
This creates kernel-core and kernel-drivers subpackages. The kernel package
remains as a meta-package the requires both of the subpackages. This allows
most installs to continue on as-is with upgrades working.
The contents of the kernel-core and kernel-drivers subpackages are determined
at build time through the filter-modules.sh script. This script "removes"
pre-defined subsystems and modules and generates a filelist for the %files
section of each subpackage. The contents of each are per-arch, with arch
override files taken into account. This allows us to make the split useful
for varying arches.