glibc / kernel issue

[Zbigniew Luszpinski]

> 1) we have kernel-headers-stable and kernel-headers
> 
> 2) our kernel-headers will always use those from linux-stable
> 
> The first one is one package more to maintain. the second one will make
> glibc not use all the recent functions/features.
> 
> Feedback?

1) split is the best because development will not affect stable. There 
will be no spikes between devs who move forward fast (me and Florin) and 
those prefering more slower movement (the rest of you?).
The benefits:
* "slower devs" can get ready code from development and put it to stable 
when they consider it stable instead of reinventing the wheel from zero. 
This would be more time and resources effective.
* an user can always switch between stable/development without changing 
distro. This is great. Espeacially when kernel is considered and someone 
just bough a new PC. I had such situation once. A guy bought a new server. 
None of Linuxes worked on it because it was too new. So I got Lunar iso 
riped off kernel and put a recent one. Works great to just install Lunar, 
then moonbase keeps it updating.

2) Off top of my head I wrote a patch for glibc which should add support 
for linux-stable.  It may or may not work. You can test it and commit if 
it fixes your problem.
To make it working without trouble always keep linux-stable version below 
or equal to kernel-headers version. If it will work depends on how much 
glibc looks at kernel-headers and how much for linux-stable headers.

If we talk about kernels we should drop linux-unstable because it is 
ridiculous. Now it is at version 3.2.13 which according to kernel.org is 
latest stable. Such name for a module is misleading.
linux-unstable should be renamed to linux-latest-stable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: glibc-linux-stable.patch
Type: text/x-patch
Size: 470 bytes
Desc: not available
URL: <http://foo-projects.org/pipermail/lunar-dev/attachments/20120401/50019ad7/attachment.bin>