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! > [EMAIL PROTECTED] / http://web2.airmail.net/vizzie/ > Whenever you find yourself on the side of the majority, it is time to > pause and reflect." - Mark Twain
