Ok guys, just keep a lid on it.
I think the symlink is the best way of handling the situation. As far as I
understand it, the symlink used to be there for when glibc was compiled, to
know what features the kernel supports etc... Since then we have popped out
"linux-headers" which basically solves this problem, and had you _not_ had to
compile anything the symlink could point to wherever the hell you wanted.
Now some packages it seems need to find out which kernel they are going to
have to operate within, and there is no way of finding this out except being
told (i.e. a symlink to the target kernel to be built for, or some kind of
variable set before compilation). I honestly think the symlink is the best
way of doing this and the env variable just complicates things.
The reason kernel modules cannot link to the "linux-headers" sources is
because they are not the running sources. If linux-headers didnt exist, every
time your recompiled your kernel you would have to recompile half your system
(as I understand it).
Also, the reason Linux told people to do all those three steps were because
that some _broken_ distros were using the /usr/src/linux symlink to build
glibc against and therefore breaking glibc when the kernel was upgraded. He
quoted that method because, even though it may not be the best method, it
works with most (even broken) distros.
If the /usr/src/linux symlink was not pointing to the current linux sources,
you would need to merge kernel related packages _after_ reboot. So when you
are installing you would need to boot into your own kernel to build, say,
network card drivers. Chicken and egg, cant fetch pcmcia-cs to install your
network card.
And by the way, the symlink is NOT obsolete, because there has been no better
method to address this situation.
Thanks,
Chris.
--
It is easier to fix Unix than to live with NT.
--
[EMAIL PROTECTED] mailing list
