[Portland] /opt setup
James Richard Tyrer
tyrerj at acm.org
Tue Jul 18 07:41:41 PDT 2006
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.
> 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. :-)
> 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).
More information about the Portland