Doing my daily emerge update, I noticed that a new release of the linux-headers, version 2.6.32, was available. After installing this new version, there appeared a message advising that glibc be re-emerged to take advantage of any new features that might be available in the latest kernel headers.
My question is: why are not glibc and the linux-headers linked in a dependency relationship? If re-compiling glibc after emerging a new version of linux-headers could be so important, why not just create an ebuild that will automatically do this via dependencies rather than provide a message that a lot of users may miss? I would like to get a few more things cleared up also. I maintain a stock Linux kernel myself rather than rely on the kernels that are available in the portage tree. Currently, I am using kernel-2.6.33, and its source tree is found in /usr/src/linux. (My package-provided file has the line "sys-kernel/vanilla-sources-9999" to prevent any rumblings from portage.) When glibc is emerged, I assume that only the headers from the linux- headers package are used and not the headers contained in the kernel source tree at /usr/src/linux. Is this correct? Also, what programs, when emerged, would directly use any kernel headers? I assume only programs that need to access hardware directly through kernel functions would need to use these headers. Of course glibc calls the kernel directly, but the only other programs that would need to do so would deal with video or sound or something similar. Is this correct? These are minor points but it is always better to understand what's happening than not understand. Frank Peters
