Mate, you don't have to take my word for it.

I'd highly recommend that you read his post, here:

Linux-Kernel Archive

Have fun! :)

That post was written in 2000 and talks about 2.2 and 2.4 kernels. I guess perhaps things have changed.

Edit: Actually older Debian documentation also says don't build kernel headers, but new documentation and the current tools do build/download headers. As I said, I don't know what to say.

Edit again: For whatever it's worth, I'm not really arguing with any confidence. I'm just reporting what I see in Debian. Also, in my own experience, I've done it the "wrong" way for a couple of years now without any incidents.

Well I haven't read anything that supercedes that advice from the Head Cheese. I'd be grateful if someone could post something (other than anecdotal evidence) which does. :)

2.6.28.7 kernel Slackware It was a must for me to build it out side the /usr/src. I had to do the make 0=/home/user name/build/kernel this created all the symlinks for compiling later. and you must use the newest nvidia out. for some reason compiling in the /usr/src/linux it built and installed but a lot of problems with the library links. that's it plus it uses the 4vl2 but it does have the squashfs modules I like it is very smooth.
so read the compiles text cd /usr/src/linux-kernel then do the build make 0=/home/user name/build kernel oldconfig

My experience is anecdotal evidence, but the Debian Kernel Handbook and the default behavior of Debian's module-assistant tool is not.

I've been Googling off and on since earlier today, and I can't find anything conclusive one way or the other. That said, I'm reasonably confident that if module-assistant's method was completely insane, lots of users would have seen the effects by now.

Unless it does more than just download & install kernel headers...

Another thought: Debian isn't really a "DIY" distro. You don't need to compile many things under Debian because of the huge software repository which is available in binary package form, installable with apt-get. This is probably why you've not experienced any problems.

Yes and no. Debian defaults to using precompiled binaries with an APT tool (apt-get, aptitude, synaptic, etc.), and most users do that. However, I compile second versions of some programs rather than using the vanilla, system-wide version - eg, Perl & Ruby - and I have a few small things that Debian doesn't have so I compile those locally as well - eg, tint.

My guess is that you're right and behind the scenes, Debian somehow manages the proper connections between libc6 (Debian's glibc) and other kernel headers.

Edit: I posted a question about this on Debian Forums, so we will see if anyone there can clear this up for us.

Good idea and thanks. Please post any repsonses back here, ok?
Cheers,
jdk

In a nutshell, the first answer made me even more confident that building and installing new headers is fine in Debian. The old advice applied when people used to link /usr/include/linux to /usr/src/linux/include/linux and in that case, you can get problems related to glibc. However, Debian no longer (for some time, I think) creates such links and thus it simply isn't a problem.

See the Debian Forums post and/or this link which explains some of the issues.

There's the answer. Thanks for clearing this up Telemachos.

Apparently, under Debian, the kernel-headers package only contains the "in-tree" headers from the kernel source and not the libc headers (which are the ones which shouldn't be updated).

Slackware installs the entire kernel source tree as a single package, which I guess isn't really necessary unless you want to re-compile the kernel after installation (which many Slackers do... :) ).

where did you see 2.6.28 in squeeze at?????

Quick answer: when I do I get this:
I should mention that I do a modest amount of apt-pinning so there are sid repos in my sources list.
cheers,
jdk

Only in unstable here:

ah ok... just curious. i didnt think 2.6.28 had made it into squeeze yet.

I don't think it has. As I mentioned above I do a modest amount of alt-pinning so I have both unstable and testing in my sources.list
Cheers,
jdk