Hi, I'll reverse the question: why are you using the links? The links are ignored anyway while compiling the kernel, so that's not it. However, you may totally confuse some other program (during compilation) that does not expect changes that are made in the kernel includes. You see, changes may be made in kernel headers in concert with other include files, which have not been upgraded, files that are not required for kernel builds, but may be required for package XYZ.
So, what else are the links good for? Most programs do not (and should not) depend on kernel version specific api's; and the handful that do should ask for and include -I/usr/src/linux anyway. Please also see the canned response below. manoj The headers were included in libc5-dev after a rash of very buggy alpha kernel releases (1.3.7* or something like that) that proceeded to break compilations, etc. Kernel versions are changed far more rapidly than libc is, and there are higer chances that people install a custom kernel than they install custom libc. The kernel headers used to make sense exporting to user space, but the user space thing has grown so much that it's really not practical any more. And technically, the symlinks really aren't very good. As of glibc, the kernel headers will really be _kernel_ headers, and user level includes are user level includes, because it is no longer possible to try to synchronize the libc and the kernel the way it used to be. The symlinks have been a bad idea for at least a year now, and the problem is just how to get rid of them gracefully. The _only_ reason for the symlinks is to immediately give access to new features in the kernel when those happen. New ioctl numbers etc etc. That was an overriding concern early on: the kernel interfaces expanded so rapidly even in "normal" areas that having the synchronization that symlinks offered was a good thing. However, the kernel interfaces aren't really supposed to change all that quickly any more, and more importantly: the technical users know how to fix things any way they want, so if they want a new ioctl number to show up they can actually edit the header files themselves, for example. But having separation is good for the non-technical user, because there are less surprises and package dependencies. Add to that the fact that few programs really need the more volatile elements of the header files (that is, things that really change from kernel version to kernel version), [before you reject this, consider: programs compiled on one kernel version usually work on other kernels]. So, it makes sense that a set of headers be provided from a known good kernel version, and that is sufficient for compiling most programs, (it also makes the compile time environments for programs on debian machines a well known one, easing the process of dealing with problem reports), the few programs that really depend on cutting edge kernel data structures may just use -I/usr/src/linux/include (provided that kernel-headers or kernel-source exists on the system). Most programs, even if they include <linux/something.h>, do not really depend on the version of the kernel, as long as the kernel versions are not too far off, they will work. And the headers provided in libc5-dev are just that. libc5-deb is uploaded frequently enough that it never lags too far behind the latest released kernel. There are two different capabilities which are the issue, and the kernel-packages and libc5-dev address different ones: a) The kernel packages try to provide a stable, well behaved kernel and modules, and may be upgraded whenever there are significant advances in those directions (bug fixes, more/better module support, etc). These, however, may not have include files that are non-broken as far as non-kernel programs are concerned, and the quality of the development/compilation environment is not the kernel packages priority (Also, please note that the kernel packages are tied together, so kernel-source, headers, and image are produced in sync) b) Quality of the development/compilation environment is the priority of libc5-dev package, and it tries to ensure that the headers it provides would be stable and not break non-kernel programs. This assertion may fail for alpha kernels, which may otherwise be perfectly stable, hence the need for a different set of known-good kernel include files. -- Marriage is a three ring circus: The engagement ring, the wedding ring, and the suffering. Manoj Srivastava <url:mailto:[EMAIL PROTECTED]> Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]