My reason for making this request is that 2.6.32 is the current long-term stable branch, meaning that it will be receive further patches for quite some time to come. As such, and given that it's a fairly strong release, it's an ideal choice for those who grow weary of the unexpected surprises yielded by each new short-lived 'stable' release. I use it, and I'm sure others do - not least hardened users as 2.6.32 remains the designated stable branch with an updated release only recently committed after a lengthy hiatus. The corresponding vanilla-sources release will obviously continue to be maintained also. If these headers remain available, it will spare us the uncertainty caused by installing system-wide headers that are in advance of the running kernel. My concern is that we might eventually reach a situation where incompatible headers are designated stable with no fallback option formally present in the portage tree ... before 2.6.32.x is formally retired upstream. At least if they are there, they can be 'pinned' where needed.
Just to add that the grsecurity maintainers have promised to support 2.6.32 long-term also: http://grsecurity.net/news.php#stablechosen
the kernel sources have no real bearing on the headers
So 1) downgrading linux-headers and recompiling glibc or 2) using linux-headers newer than the kernel and recompiling glibc are both safe operations and wont render any production servers inoperable?
i dont know why you're so concerned with wasting time on rebuilding glibc, but no, neither of those operations are dangerous
*** Bug 325979 has been marked as a duplicate of this bug. ***
*** Bug 347149 has been marked as a duplicate of this bug. ***
*** Bug 423325 has been marked as a duplicate of this bug. ***
