kernel-headers-2.4 module

[Auke Kok]

Moritz Heiber wrote:

>On Thu, 20 Jan 2005 15:36:53 +0100
>Moritz Heiber <moe at lunar-linux.org> wrote:
>
>  
>
>>On Thu, 20 Jan 2005 14:22:32 +0100
>>Jasper Huijsmans <jasper at lunar-linux.org> wrote:
>>
>>    
>>
>>>I would choose (b).
>>>      
>>>
>>mmm .. guess we could put up a script on espresso that does the job
>>automaticly ..
>> 
>>    
>>
>>>(c) could be to use redhat (or debian or suse or ...) 2.4 kernel
>>>headers, which have been 'sanitized', like the 2.6 headers. Don't
>>>know if that is needed or if it is available at all.
>>>      
>>>
>
>So this turns out to be a lot more complicated than I expected it to be.
>Basicly, we might have to have a seperate tarball for every kernel
>module we currently maintain since the patches applied to the -agr or
>-grsec kernels are modfiying the headers too.
>So what should we do?
>
>Provide one tarball of kernel headers that comes from the 'pure' kernel
>source tree?
>Provide seperate tarballs for every kernel module?
>
>or ...
>
>abandon the concept of kernel header modules and go back to linking the
>headers from /usr/src/linux to /usr/include/ .. (I can't remember why we
>opted against staying around that matter .. anybody willing to remind me
>of the reason for it?).
>
>
hehe

because we usually do the right thing. The right thing still is "to copy 
the kernel headers from the kernel sources to /usr/include that glibc 
was compiled against".

that means:

1) once glibc finishes compilation, the kernel headers should be copied

( so either glibc or the 'kernel-headers{-2.[46]}' module should perform 
this task )

2) a kernel recompile should not change the headers in /usr/include

( so symlinks are a no-no )


now if we make glibc/POST_INSTALL call a recompile of kernel-headers, 
and kernel-headers installs them properly (2.4 or 2.6 or not) into 
/usr/include... we're all fine

unless people somehow screw up their kernel-headers. In that case you 
should not have to 'lin glibc'. Now if 'lin kernel-headers' does a fatal 
attempt to use the ones found in /usr/include .... you might be saved. 
Otherwise the only true way to properly restore them is to compile a 
kernel (if needed), then compile glibc(if needed), and then copy the 
headers again (lin kernel-headers).

This is what I prefer. I do not want 20 tarballs on the server with 
mismatching versions, because that makes my life a nightmare and won't 
work (openmosix headers? anyone? grsec?) in some cases.

my preferred solution would just to remove the tarball generation from 
glibc and put that in a uniform 'kernel-headers' module. This module 
would not generate a tarball in /var/spool/lunar, but just cp the stuff 
properly directly from /usr/src/linux over to /usr/include.

sofar