Re: Interpreting FHS

[Jarno Elonen <jarno@elonen.iki.fi>]

> In my understanding: /opt is for packages that do not fit into the unix file 
> system structure with the defined dirs like bin, lib, etc.
> What you now want to do with /opt is to make it to something like C:\programs 
> on Windows systems.

Just as a side note (NOT as a proposition by any means!):
what's really so wrong in C:\program files style? Of course, on
open systems, instead of vendor specific directories, there should be some
other subdirectory policy (lsm for example?).

If there were a way to remove symlinks when the original file is removed,
I think the following structure would be the easiest to understand and
administrate:

  + usr
    + bin
      + qtcups -> ../qtcups/bin/qtcups
      + nano -> ../nano/bin/nano
    + sbin
      + traceroute -> ../traceroute/bin/traceroute
    + qtcups
      + etc (conf)
      + share (data)
      + bin (binaries)
      + doc (man, info)
    + nano
      + etc
      + bin
      + doc
    + traceroute
      + etc
      + bin
      + doc

...and even:

    + kde -> kde2.2
    + kde2.2
      + kmail
      + konqueror
    + kde3
    + bin
      + kmail -> ../kde/kmail/bin/kmail

...or EVEN (a matter of policy again):
    + usr
      + X11R6
        + kde -> kde2.2
        + kde2.2
      ...

Then, you could easily try different versions and remove whole
packages manually without having to guess where their may have installed
their binaries, libraries, configuration files, data, documents etc
etc. Of course, this is pure fantasy since there are no "2-way links". If
there were, however, this model could well be made reasonably backwards
compatile.

Does it make any sense? I.e. have I missed some important aspect of Unix 
here?

- Jarno