1 |
Linus meant that the kernel headers shouldn't be a moving target -- |
2 |
changing the kernel headers w/o accounting for all the packages that |
3 |
rely on them is dangerous. It has the potential to break glibc which |
4 |
virtually everything in a Linux system depends on. |
5 |
|
6 |
I'd also like to mention that Gentoo is not alone in providing a kernel |
7 |
headers package -- I know Debian and Red Hat do, as well. However, they |
8 |
have life easier than Gentoo due to its source-based nature. In binary |
9 |
distributions, they have to rebuild their binary packages when they |
10 |
update the kernel headers, so those get updated as well. All Gentoo can |
11 |
do is remind the user that new kernel headers are installed and thus |
12 |
certain packages require rebuilds as well even if they don't have new |
13 |
versions, and I don't think it even does that. |
14 |
|
15 |
On Thu, 2005-03-31 at 00:24 +0200, peter.gantner@×××××××××××××.at wrote: |
16 |
> Quoth fire-eyes, on Wednesday, the 30th of March: |
17 |
> |
18 |
> > I have noticed a bit of noise here on the topic of 2.6 versions of |
19 |
> > linux-headers. |
20 |
> |
21 |
> Yes. |
22 |
> |
23 |
> As the topic has cropped up I want to ask a question that has bothered me |
24 |
> for quite some time now. |
25 |
> |
26 |
> In a LKML post [1] about the symlinking of /usr/include/linux to |
27 |
> /usr/src/linux/include/ which has been done for quite some time in older |
28 |
> Linux distributions, Linus calls doing this "instanity" and states that the |
29 |
> kernel headers used to compile glibc and friends should always be taken |
30 |
> from the glibc distribution (which includes a patched set of kernel |
31 |
> headers) and one should not use the headers from the kernel.org tarball. |
32 |
> |
33 |
> But this is exactly what Gentoos linux-headers package does: get the kernel |
34 |
> tarball and install the required files. The result is in effect not really |
35 |
> different from the old symlinking method. |
36 |
> |
37 |
> Now am I misreading Linus' recommendation? |
38 |
> When he sais: |
39 |
> |
40 |
> > Basically, that symlink should not be a symlink. It's a symlink for |
41 |
> > historical reasons, none of them very good any more (and haven't been for |
42 |
> > a long time), and it's a disaster unless you want to be a C library |
43 |
> > developer. Which not very many people want to be. |
44 |
> |
45 |
> > The fact is, that the header files should match the library you link |
46 |
> > against, not the kernel you run on. |
47 |
> |
48 |
> and later: |
49 |
> > [...] you should not use the kernel headers: You should use the headers |
50 |
> > that glibc came with. It is probably a Red Hat bug that those headers |
51 |
> > were a symbolic link. |
52 |
> |
53 |
> Does that mean: |
54 |
> a) glibc comes with patched kernel headers that should always be used when |
55 |
> compiling other applications/libs |
56 |
> or |
57 |
> b) it doesn't matter what kernel headers you use to build your glibc with |
58 |
> as long as any apps that use glibc use the very same headers at compile |
59 |
> time. |
60 |
> |
61 |
> Thanks in advance for clarifying(sp?) this. |
62 |
> |
63 |
> Peter G. |
64 |
> |
65 |
> [1] http://linuxmafia.com/faq/Kernel/usr-src-linux-symlink.html |
66 |
> |
67 |
-- |
68 |
gentoo-server@g.o mailing list |