[Portland] /opt setup

[James Richard Tyrer]

George Kraft wrote:
> */James Richard Tyrer <tyrerj at acm.org>/* wrote:
> 
>     With all these links, is there really any point in installing an
>     application in: "/opt/"? I suppose so, but I can't help but wonder.
> 
> Here is the original FHS rationale.
> 
> http://www.pathname.com/fhs/2.2/fhs-3.12.html
> 
> What do you do if three different vendors want to install Java?  The 
> /opt/vendor/product/ resolves that.  What do you do if you want to 
> install multiple versions of the same product?  What do you do if you 
> want to install both ppc32 and ppc64?   The /opt/ isolates the vendor so 
> they only polute their namespace subdirectory.  :-)
> 
> http://lsbbook.gforge.freestandards.org/pack-adv.html
> 
> In short, /opt/ is to protect /usr/ from insane 3rd party packages.
>
Yes, this is the rational.  It is also why apps installed in: "/opt/" do 
not make links for their executables.

IIUC, your method would defeat this rational since everything would be 
linked to: "/opt/bin/", "/opt/lib/", "/opt/man/", "/opt/<etc>/" and you 
are back to having collisions.  This is what I said that all the links 
will defeat the purpose of installing in: "/opt/".

The method which OpenOffice uses works, however it would work just as 
well if it were installed in: "/usr/local/OpenOffice-<version>/".  And 
Firefox and Thunderbird binaries do install in: "/usr/local/<app_name>/" 
  -- for some reason they don't use a version number (go figure since 
you get folders with version numbers if you build Firefox from source).

Note that I don't see this method, using a shell script to start the 
application as a really good idea; it is really a kludge -- but it does 
work and the only issues with installing like Firefox and Thunderbird 
binaries in: "/usr/local/<app_name>" is that to install multiple 
versions you need a version number (if the app doesn't provide it, the 
user needs to add it) and the menu entries (they will probably collide).