| 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 |
Archives