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@xxxxxxxxxxxx> Ph.D. Candidate, Department of Applied Physics, Stanford University
