Re: [gentoo-server] linux-headers: insanity? WAS: linux-headers update?

[Kerin Millar]

Wes Kurdziolek wrote:
> Linus meant that the kernel headers shouldn't be a moving target --
> changing the kernel headers w/o accounting for all the packages that
> rely on them is dangerous.  It has the potential to break glibc which
> virtually everything in a Linux system depends on.

Sorry but that's not simply not correct. Changing the headers does 
absolutely *nothing* unless you (re)build a package that includes a 
portion of those headers. After all, they are simply headers - it's not 
a library. The issue arises if you build said package against headers 
which are *newer* than the kernel you are running.

There is absolutely no requirement to rebuild anything if you upgrade 
your headers. The breakage of glibc can occur as follows (just to 
provide an example):

1) You have system-wide linux-headers-2.6.8 and you run kernel-2.6.8. 
All affected packages have been built against those headers.
2) You update linux-headers-2.6.8 to linux-headers-2.6.9.
3) You _opt_ to rebuild, say, glibc (and yes, it is entirely optional).
4) glibc now makes use of kernel API functions which are in advance of 
the kernel you are still running - b0rkage. In this case, you'd either 
have to rebuild glibc against <=linux-headers-2.6.8 or upgrade to 
 >=kernel.2.6.9.

The message that the linux-headers ebuild displays is simply a 
recommendation i.e. "you might like to rebuild glibc now to leverage the 
kernel in so far as possible". It's not mandatory.

> I'd also like to mention that Gentoo is not alone in providing a kernel
> headers package -- I know Debian and Red Hat do, as well.  However, they
> have life easier than Gentoo due to its source-based nature.  In binary
> distributions, they have to rebuild their binary packages when they
> update the kernel headers, so those get updated as well.

No, they don't have to. The last time I checked, the standard headers 
package in Debian was comparatively ancient - based on a 2.5 snapshot if 
I recall (it's reasonable to assume that these are the headers they use 
when generating their packages). It might not be optimal, but the point 
is this: it doesn't matter from the point of view of functional 
integrity. They make available newer headers packages but there is 
absolutely no requirement for them to rebuild their packages against 
newer headers as long as the standard kernel they ship is not older than 
the headers (which is invariably the case).

Lots of people are running 2.6 kernels on systems that were built with 
2.4 headers. I've also heard of people running 2.4 kernels on distros 
built with 2.2 headers and it wouldn't surprise me if you could even run 
a 2.6 kernel on a system built with 2.2 headers.

Perhaps some packages may be released that mandate certain headers (for 
example, if they wanted to use the CryptoAPI functions which are only 
available in 2.6 in vanilla terms). In those cases, I'd imagine that 
they would use the "bad" method of traversing /usr/src/linux rather than 
using the system-wide headers, just as 3rd party kernel modules do. I'm 
not aware of any such packages though.

What Linus was complaining about was distros that don't use independent 
system-wide headers at all and, instead, use the hack of symlinking 
/usr/include/linux and /usr/include/asm to their counterparts in a 
kernel source tree. That's a terrible thing to do, it means that any 
package you build that uses kernel headers will be affected according to 
your "kernel du jour" which greatly increases the likelihood of 
breakage. This is why Gentoo uses independent headers which are 
generally *not* a moving target, as does just about any decent distro 
these days. But with Gentoo you still have to ensure that you do not 
upgrade your headers in advance of your kernel version *and* rebuild 
packages against them. This usually isn't an issue; the headers tend to 
be several steps behind any kernel available in portage. The only reason 
it's an issue now is because Gentoo have now pushed 2.6 as part of the 
"default" 2005.0 profile.

Finally, can 2.4 users please not mess around with package.masks and the 
like except where it is strictly necessary. The correct way to do this 
is to link to the 2005.0/2.4 profile as I have mentioned already:

# cd /etc
# rm make.profile
# ln -s ../usr/portage/profiles/default-linux/x86/2005.0/2.4 make.profile

Regards,

--Kerin Francis Millar
--
gentoo-server@g.o mailing list