No more kernel-source(code) ??? (was: rawhide report: 20040623 changes)

[Daryll Strauss]

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