[MPlayer-users] Compile with new kernel

[Gábor Lénárt]

On Tue, Aug 05, 2003 at 05:03:36AM -0400, D Richard Felker III wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> On Tue, Aug 05, 2003 at 10:12:24AM +0200, Gábor Lénárt wrote:
> > [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> > On Mon, Aug 04, 2003 at 06:10:59PM +0200, gabucino at mplayerhq.hu wrote:
> > > [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> > 
> > > Gábor Lénárt wrote:
> > > > Gabu, otherwise you asked me to show an example for the badness of symlink
> > > > issue here "in the real life". So here it is.
> > > ?
> > > Where?
> > 
> > Read the mail again :)
> 
> It's not there. What Gabu and I asked for, and what you are unable to

OK, so again, quoted from my mail:

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)