I'll throw this out as a straw man based on what I've been reading: 1) /usr/lib/`uname -r`/build continues to exist as part of the kernel package. This covers what most people who do want to build modules for their currently running kernel. 2) A new kernel devel package is created. It includes headers for ALL kernels that have been released for a distribution. They'd be placed in different directories (maybe /usr/src) with some naming scheme that includes kernel release, smp, architecture, etc. This package would get new sets of headers added to it every time a new kernel release comes out. Pros: ----- * For most users #1 is sufficient, small, and easily automated. * For people building drivers for distribution #2 covers everything they might need without requiring them to keep reconfiguring a kernel tree. * #2 is probably smaller than kernel-source even with a bunch of kernel versions, but this should be checked. The distribution CD is definitely small because it only has one set of headers. * #2 can be a normal package with version numbers that is probably the same as the kernel version numbers. * #2 can be safely installed without screwing up a running system because #1 always exists and #2 installs in a different tree. * There's only a little duplication (one header tree) between #1 and #2. * #2 has no issues with SMP kernels on non SMP machines. * Even if third parties make new kernel packages they can also release kernel-devel that is a includes everything from the stock kernel-devel and adds their header tree under a unique name. * Kernel modules probably don't need a requirement on this package because they'll be building based on /lib/modules/`uname -r`, but they could if they want everything. * Kernel module builders can loop over all the header trees and build every possible configuration. Cons: ----- * Creating #2 is a bit tricky. The headers are essentially generated by kernel package builds. I'd think you'd add new source tarballs to the source RPM that contain the headers for the next batch of kernels. It's an additional step after building all the kernel packages, but this grief is limited to the building of kernel packages so it's only done once and everyone benefits afterward. * The kernel-devel package keeps getting bigger. Someone should do some calculations based on FC1 to figure out how bad this will be. How does this do meeting everyone's requirements? Shoot it full of holes. I'm just an neutral 3rd party who's been reading this thread for way too long. :) - |Daryll
