[MPlayer-users] Compile with new kernel

[Gábor Lénárt]

On Mon, Aug 04, 2003 at 01:29:54AM +0200, gabucino at mplayerhq.hu wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]

> Gábor Lénárt wrote:
> > And /usr/include/linux belongs to glibc!
> :))
> Then why is it in the kernel tarball? :)

OK, this was not a clear statement. I meant it should be kernel headers
from the kernel you were compiling glibc with.

Gabu, otherwise you asked me to show an example for the badness of symlink
issue here "in the real life". So here it is.

Standards ARE good. FHS specifies that /usr/include/linux should NOT BE
a symlink into SOME kernel source (just check it). Since more and more
distributions follows FHS, it may be a problem to write a program which
depends on the situation where /usr/include/linux is a symlink to the
actual kernel source.

Eg, you may write a program to use new features of fbdev can be found in
2.6.x kernels. So you include files from /usr/include/linux, and yes, it
will work for YOU, since you have a symlink. But not on distros following
FHS. You can say here: "hey, who cares, it works for me". But there is
a problem here. This mentality is similar to Microsoft. Microsoft often
incorporates standards into their products with some little modification.
And m$ says: "here it works for m$ windoze, use windoze". But of course
this is NOT the solution! It's more like to modify TCP/IP just because
you think it would be better that way. And the strange thing here, that
you MAY BE RIGHT! But even if you're right you SHOULD NOT do this, otherwise
other people wouldn't be able to connect to your machine with TCP/IP.

So in nutshell: you can say that FHS is bad, and maybe you're right. But
because there is no real alternative which control this situation, you
should follow FHS, otherwise many-many distros will fail to compile your
code I've described in my example.

- Gábor (larta'H)