[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: File Systems.

* "H. Peter Anvin" <hpa@transmeta.com> wrote:
> Actually, since the *only* reason for /opt is to break up installed
> software in manageable pieces, /opt/<package> is definitely to be
> recommended. 

There is no reason to do this in a given system with a working
package-manager. The only reason for /opt has been the need of
Unix-vendors to separate their OS from 3rd party applications and don't
let them install straight between the OS. Since Linux-vendors
(distributors) look at everything they deliver as "their OS", /opt is
nearly not used at all. And exactly this attitude of "All of
Redhat/SuSE/Debian/Mandrake is Linux" gives many problems in defining
(or specifying) what Linux actually is. So, come on: What is Linux? I'm
asking this since years and nobody can give me an answer. The LSB has to
give an answer.

> However, putting symlinks in /opt/bin, /opt/lib et al is good
> practice.
> For packages too small to bother, /usr is just as well.

So everything in /usr is part of the OS? Including
"/usr/bin/netscape-navigator" and such? On the system I'm writing this
there are 1110 executables in /usr/bin.

IMHO the FHS is right with regard to /opt, since it does not try to say
what Linux is. But the LSB has to and so it could (has to) refine that.
Saying "all software implementing stuff not specified by LSB must not go
to /usr but to /opt" wouldn't object FHS, just interpret or refine
it. If this follows the /opt/<package> approach or doubles the structure
of /usr in /opt doesn't matter, one could do both according to the needs
of the specific packages.

I have still not read one argument in favor of mixing everything up in
/usr that could point on an advantage of this approach. I see lots of
disadvantages though.


Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Reply to: