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