Originally Posted by HappyTux
I fail to see what point you are trying to make here the likelyhood of something like that happening on a Debian system are next to nil if using it properly.
The key thing being that one is, in fact, setting their system up correctly. Consider the usual way building a kernel goes; generally something like:
fakeroot make-kpkg clean
fakeroot make-kpkg --append-to-version ".ddmmyyyy" --revision ".acme.1.0" --us --uc --initrd kernel_image kernel_headers
You build the kernel image package and the kernel headers package at the same time. Those two are the ones that have to match. If you're doing kernel (non-userland) development. That's what seems to throw a lot of people.
The thing of it is, a substantial number of things - macros, API calls, and so on - changed between the 2.6.18 kernels and the 2.6.2x kernels. So, if you're using the headers only, and not the full kernel source, to build an out-of-tree module: and a number of modules have started using that approach, it saves an enormous amount of disk space: say, for example, you're building the ATI fglrx driver; that's one example of an out-of-tree kernel module that's adopted this approach - as you're using the kernel headers from the wrong version of the OS, while the driver may build, God only knows what it's going to do when you load it.
In order to get in that situation you would need to force the install of a package on a branch of Debian it was not built for or get caught in the middle of a libc6 (glibc on Debian) transition from unstable down to testing or mixing stable with testing/unstable. Anyways we are filling up buddies thread with this when it is not relevant to the problem at hand...
While you're correct in your assertion that one could screw up their system by forcing an install of the wrong kernel, there are a number of different ways to end up with a mismatch.
The long and short of it is this: one should use the kernel headers for kernel development, and the headers that came with the glibc you're using for userland / user-space development. A lot of the files have the same names, and the include directory has pretty much the same layout, but the two sets of headers are for completely different purposes. A quote from an email from Linus was referred to earlier; if you read down through it a little more, you'll find a statement from Linus to the effect that:
No. He really meant that you should not use the kernel headers: You should use the headers that glibc came with.
That's pretty much it. You don't need to update the header files you're using to compile purely user-space apps when you change kernels. However, you absolutely need to use the headers that match the kernel you're running when you're building modules for that kernel.
Hope that helps clear things up some; for what it's worth, until it was explained to me, I was confused as all get-out by it.