Split off kernel-header/devel package (was: No more kernel-source(code) ???)

[Per Bjornsson]

On Mon, 2004-06-28 at 03:58, Axel Thimm wrote:
> On Mon, Jun 28, 2004 at 12:40:22PM +0200, Arjan van de Ven wrote:
> > actually it 100% is. kernel-devel, if it ever comes to a reasonable
> > thing, will be in *addition* to what is there right now not as
> > replacement.
> 
> Maintaining two solutions for the same problem? It is per definition
> error-prone and predestined that one of them will deteriorate over
> time.

But it's not "two solutions for the same problem"! First, it's not
really the same problem. The /lib/modules/`uname -r`/build tree is very
useful for quickly building modules against an installed kernel, either
for developers of external kernel modules or for end-users who want to
try out some kernel module that isn't available in packaged form, while
a kernel-devel package that contains all headers for a whole bunch of
kernels would be most useful for packagers who want to have packages
covering the full range of kernels.

Second, it's not really "two solutions" - it seems to me that the most
reasonable thing to do would be to snag the _same files_ that go into
the individual kernel packages and stuff them into the kernel-devel
package with some path that includes the architecture. This should be
possible to fully automate in the SRPM and does not have to be prone to
bitrot at all.

Personally I can't see why the kernel-devel package should contain
headers for "all released kernel versions", that just seems to make the
creation of that package harder to me. I think that the sanest way of
doing it would just be to have a kernel-devel package for each released
kernel version, and simply have it contain exactly the contents of all
kernel variations (i586, i686,...). These packages should be parallel
installable (just like different kernel versions are), and should
preferably be handled just like the kernel in apt/yum/up2date. (I guess
that's a question for the developers of those tools though, as far as I
know they are just special-casing the kernel based on the package name
and doing the equivalent of 'rpm -i' instead of 'rpm -U' for new
versions?) 

Now, I could agree that given a kernel-devel package it would be
possible to build any correctly written module without including the
files again in /lib/modules/`uname -r`/build, but that is the officially
documented way of doing it and it would be a shame to break the official
convention. The alternative would be a symlink of course, but then
you're forcing everyone who wants to do a quick module build to include
the stuff needed for all architectures (since that's what's in the
hypothetical kernel-devel package).

Best regards,
Per Bjornsson

-- 
Per Bjornsson <perbj at stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University