1 |
now that the 2.6 headers have entered a sane state and are *quite* nice to |
2 |
work with, i have no inclination whatsoever to touch unsanitized headers |
3 |
(keep your puns to yourself :p) |
4 |
|
5 |
so here's the question i pose: what to do ? |
6 |
|
7 |
people file bug reports saying "package FOO fails to build with linux-2.4.xx |
8 |
headers" ... my answer is "well, that sucks, but package FOO is not going to |
9 |
be changed as it builds correctly with sanitized linux-2.6.xx headers" |
10 |
|
11 |
do we want to try and maintain our own sanitized 2.4 headers ? this would |
12 |
require our own git tree as trying to do development on a patch-based setup |
13 |
is an exercise in insanity ... |
14 |
|
15 |
or perhaps we want to unmask the sanitized 2.6 headers for use on a 2.4 |
16 |
profile ? the core ramifications: beneficial actually; we tell glibc what |
17 |
the min kernel version it needs to run on (2.4.1 currently), and it will |
18 |
enable all features required between that and whatever kernel version your |
19 |
headers are ... so if you were to upgrade your kernel, glibc would |
20 |
automatically take advantage of the newer system calls |
21 |
-mike |