Re: Cross posting per request
Larry,
They intend to implement /opt as a major mount point. They also plan to
make /usr/local a very dangerous place to play. :)
I hope that Debian will make a policy of staying out of /usr/local.
This is way it is shaping up for each application:
Beside the binary in /usr/bin or /bin.
There will be a /usr/libexec subdirectory for each application.
There will be a /usr/share subdirectory for each application. They
specify the contents of this directory to be "architecture independent
data".
/var is in a serious state of flux and I think that this will go to pot
like /usr/lib is now. About half of it is currently local and half
currently non-local.
They seem to be refusing to fix ridiculous things like /usr/games and
putting /dev/MAKEDEV where it belongs in /sbin.
Well actually the FHS people are pretty set on this
> Greg Hudson writes:
> -> >> In addition, the admin's life would only be made easier.
> ->
> -> > "Let's see where is perl stuff....of course: /usr/perl"
> ->
> -> Of course it looks easier if you only ask one question.
> ->
> -> "Where are the operating system binaries that should go in users'
> -> paths?"
> ->
> -> "Where are the standard C++ libraries? Where is the termcap library?"
> ->
> [ Rest of Greg's excellent explanation deleted ]
> I couldn't have said it better myself. :)
> This is the most compelling argument for the status quo. With the
> suggested changes, mapping a program to it's associated files gets
> slightly easier, but mapping a type of file or specific file to it's
> location in the filesystem gets much harder. It's probably one of the
> reasons why /opt hasn't caught on too well with 3rd party
> platforms. (Well, that and support for multiple platforms :)
> -Larry
> --
> Larry Daffner | Linux: Unleash the workstation in your PC!
> vizzie@airmail.net / http://web2.airmail.net/vizzie/
> Whenever you find yourself on the side of the majority, it is time to
> pause and reflect." - Mark Twain
Reply to: