Kernel-headers module and glibc mod changes

[elaine]

Jasper,

Correct (see below). If we decide to 'bless' particular header tarballs
then they may be put into the moonbase (with an md5 which won't work for 
this approach because at the very least the timestamps in the tarball
will vary).

I figured this gives us the best of both approaches. I figured defaulting
to local generation of the module sources is a simple approach.

Unfortunately glibc/POST_INSTALL as I posted it lastnight didn't work
because 'lin' is disabled unitl 'lin glibc' has completed. As an 
expedient, for the moment I"ve copied the kernel-headers/BUILD file 
actions into POST_INSTALL, but I'm going to see now if I can kill the 
glibc lock prior to starting 'lin -c kernel-headers'.

elaine

> Hi elaine,
> 
> I'm a bit confused. This works a bit different than I expected.
> 
> In your new modules you copy the headers from /usr/src/linux after
> recompiling glibc. This is what niki proposed in the meeting. 
> 
> It is also, I believe, what was rejected in favour of a more static
> approach to kernel headers, to avoid relying on the kernel-du-jour and
> the /usr/src/linux symlink that can point anywhere.
> 
> As I understood it, the idea was to create a static kernel header
> package, based on the ISO kernel (2.4.22) and keep that package until we
> are ready to move to 2.6 headers.
> 
> Please tell me if I'm wrong.
> 
> 	Jasper
> 
> PS
> The module looks good, BTW. I'm sure it will work without problems.
>