1 |
My point entirely. I just used fewer words and left out the |
2 |
nitty-gritty. Thanks for covering the details, though. |
3 |
|
4 |
On Thu, 2005-03-31 at 16:02 +0100, Kerin Millar wrote: |
5 |
> Wes Kurdziolek wrote: |
6 |
> > Linus meant that the kernel headers shouldn't be a moving target -- |
7 |
> > changing the kernel headers w/o accounting for all the packages that |
8 |
> > rely on them is dangerous. It has the potential to break glibc which |
9 |
> > virtually everything in a Linux system depends on. |
10 |
> |
11 |
> Sorry but that's not simply not correct. Changing the headers does |
12 |
> absolutely *nothing* unless you (re)build a package that includes a |
13 |
> portion of those headers. After all, they are simply headers - it's not |
14 |
> a library. The issue arises if you build said package against headers |
15 |
> which are *newer* than the kernel you are running. |
16 |
> |
17 |
> There is absolutely no requirement to rebuild anything if you upgrade |
18 |
> your headers. The breakage of glibc can occur as follows (just to |
19 |
> provide an example): |
20 |
> |
21 |
> 1) You have system-wide linux-headers-2.6.8 and you run kernel-2.6.8. |
22 |
> All affected packages have been built against those headers. |
23 |
> 2) You update linux-headers-2.6.8 to linux-headers-2.6.9. |
24 |
> 3) You _opt_ to rebuild, say, glibc (and yes, it is entirely optional). |
25 |
> 4) glibc now makes use of kernel API functions which are in advance of |
26 |
> the kernel you are still running - b0rkage. In this case, you'd either |
27 |
> have to rebuild glibc against <=linux-headers-2.6.8 or upgrade to |
28 |
> >=kernel.2.6.9. |
29 |
> |
30 |
> The message that the linux-headers ebuild displays is simply a |
31 |
> recommendation i.e. "you might like to rebuild glibc now to leverage the |
32 |
> kernel in so far as possible". It's not mandatory. |
33 |
> |
34 |
> > I'd also like to mention that Gentoo is not alone in providing a kernel |
35 |
> > headers package -- I know Debian and Red Hat do, as well. However, they |
36 |
> > have life easier than Gentoo due to its source-based nature. In binary |
37 |
> > distributions, they have to rebuild their binary packages when they |
38 |
> > update the kernel headers, so those get updated as well. |
39 |
> |
40 |
> No, they don't have to. The last time I checked, the standard headers |
41 |
> package in Debian was comparatively ancient - based on a 2.5 snapshot if |
42 |
> I recall (it's reasonable to assume that these are the headers they use |
43 |
> when generating their packages). It might not be optimal, but the point |
44 |
> is this: it doesn't matter from the point of view of functional |
45 |
> integrity. They make available newer headers packages but there is |
46 |
> absolutely no requirement for them to rebuild their packages against |
47 |
> newer headers as long as the standard kernel they ship is not older than |
48 |
> the headers (which is invariably the case). |
49 |
> |
50 |
> Lots of people are running 2.6 kernels on systems that were built with |
51 |
> 2.4 headers. I've also heard of people running 2.4 kernels on distros |
52 |
> built with 2.2 headers and it wouldn't surprise me if you could even run |
53 |
> a 2.6 kernel on a system built with 2.2 headers. |
54 |
> |
55 |
> Perhaps some packages may be released that mandate certain headers (for |
56 |
> example, if they wanted to use the CryptoAPI functions which are only |
57 |
> available in 2.6 in vanilla terms). In those cases, I'd imagine that |
58 |
> they would use the "bad" method of traversing /usr/src/linux rather than |
59 |
> using the system-wide headers, just as 3rd party kernel modules do. I'm |
60 |
> not aware of any such packages though. |
61 |
> |
62 |
> What Linus was complaining about was distros that don't use independent |
63 |
> system-wide headers at all and, instead, use the hack of symlinking |
64 |
> /usr/include/linux and /usr/include/asm to their counterparts in a |
65 |
> kernel source tree. That's a terrible thing to do, it means that any |
66 |
> package you build that uses kernel headers will be affected according to |
67 |
> your "kernel du jour" which greatly increases the likelihood of |
68 |
> breakage. This is why Gentoo uses independent headers which are |
69 |
> generally *not* a moving target, as does just about any decent distro |
70 |
> these days. But with Gentoo you still have to ensure that you do not |
71 |
> upgrade your headers in advance of your kernel version *and* rebuild |
72 |
> packages against them. This usually isn't an issue; the headers tend to |
73 |
> be several steps behind any kernel available in portage. The only reason |
74 |
> it's an issue now is because Gentoo have now pushed 2.6 as part of the |
75 |
> "default" 2005.0 profile. |
76 |
> |
77 |
> Finally, can 2.4 users please not mess around with package.masks and the |
78 |
> like except where it is strictly necessary. The correct way to do this |
79 |
> is to link to the 2005.0/2.4 profile as I have mentioned already: |
80 |
> |
81 |
> # cd /etc |
82 |
> # rm make.profile |
83 |
> # ln -s ../usr/portage/profiles/default-linux/x86/2005.0/2.4 make.profile |
84 |
> |
85 |
> Regards, |
86 |
> |
87 |
> --Kerin Francis Millar |
88 |
> -- |
89 |
> gentoo-server@g.o mailing list |
90 |
> |
91 |
-- |
92 |
gentoo-server@g.o mailing list |