On Wed, 18 Mar 2009 23:49:12 +0200 Alan McKinnon <[email protected]> wrote: > > msoul...@anton:~$ equery belongs /usr/include/linux/quota.h > > [ Searching for file(s) /usr/include/linux/quota.h in *... ] > > sys-kernel/linux-headers-2.6.23-r3 (/usr/include/linux/quota.h) > > > > ul...@anton:~$ uname -a > > Linux anton 2.6.25-gentoo-r8 #9 Sun Nov 23 19:14:08 EST 2008 i686 AMD > > Athlon(tm) XP 1700+ AuthenticAMD GNU/Linux > > > > So slightly off but compatible. At some point a newer glibc would simply > > fail to build if it's incompatible then, I assume? > > It is as close to guaranteed to build as you are ever going to get. The > public > interface to the kernel via it's headers simply does not change in > incompatible ways. > > But if it ever did, then yes, glibc would fail to build
This was a doubt of mine. One of the reasons I prefer to use a stable kernel is that I don't know if, when using a newer (and ~x86) kernel, I should also use the corresponding linux-headers version. So you say I can be 99.999% sure that, should I update my kernel (say, to 2.6.28) and meet problems, those will be intrinsic to this kernel version (and possibly to incompatibilities with things like out-of-tree kernel modules), but never because the kernel headers are outdated? IOW, the only real problem of using outdated kernel headers is not fully taking advantage of new features? I prefer to use stable software anyway, but it is important to know.
