Surely this is missing a fundamental point: we, the Debian project,
have to ship binaries that will work on everybody's system, so that
our users can use the kernels that they choose.
Furthermore, we have to do this while running all manner of kernels
ourselves.
If the kernel system call interface has changed in such a way that
binaries compiled against old kernel headers will do terrible things
when run on new kernels, or vice versa, then surely this is (a) a
problem with the kernel developers not thinking enough about backward
compatibility and (b) not something we can solve by using a particular
set of headers ?
Changes to kernel interfaces breaking the odd program so that they
need to be upgraded is OK, if something of a pain, but changes which
make the old programs work but insecurely (for example) are
pernicious, as are changes which mean that it's impossible to compile
a program so that it works on both old and new kernels.
All of this has little to do with whether we ship a particular set of
kernel headers with our libc package - in fact, if we were to upgrade
our libc to contain 2.0 headers then we would at least be able to
build binaries with 2.0 headers without necessarily requiring all of
our developers to upgrade to 2.0 simultaneously.
A Linux distribution is a very large piece of software engineering,
and comes is a point where expecting its maintainers to play
`catch-up' continuously with new and sometimes-incompatible kernel
interfaces is unreasonable.
Expecting the users to know to upgrade everything at once is
unreasonable too, IMO.
Ian.
(maintainer of dpkg)