5 ms·

Because Oracle cannot install to /usr/local/oracle? I don't see the value of /opt.

claudius 14y ago
/usr/local is meant to replicate /usr in the way that binaries go into /usr/local/bin, libraries into /usr/local/lib etc., but for software that isn’t managed by the package manager – at least that’s what it is used for nowadays. So a well-behaving software would happily go into /usr/local, whereas the ugly software things that want their own folder somewhere better go into /opt.
- FooBarWidget 14y ago
  And why is that distinction important? It seems a fairly arbitrary rule to me. What's the problem with dropping stuff in /usr/local/foo?
  - e12e 14y ago
    It's not set in stone. I also prefer having packages with their own hierarchies under /opt, rather than /usr/local/<package> -- in general stuff under /usr/local should put their binaries in /usr/local/bin -- their manpages under /usr/local/share/man, headers and libraries in the corresponding places -- so that I don't have to mess with my PATH settings to be able to run a command, look up a man page or link against a library. Sometimes software isn't packaged for use on a posix-like system -- and then I might have to do some dancing to get it to work -- I usually prefer having such programs under /opt/<program-version>. I do have another folder under local: /usr/local/xstow -- so I can easily compile packages and manage different versions under /usr/local/xstow/package-x.y.z. http://xstow.sourceforge.net/ http://xstow.sourceforge.net/
buster 14y ago
Because, maybe, but only maybe, there might be software that is not split up into lib, bin, doc directories and that doesn't log into /var/log?! There actually is quite some software like that and sometimes it even has a technical reason. Especially some commercial and proprietary software that runs on Windows, HP-UX, SCO, AIX, Solaris and Linux tends to go the "easy way" of packaging and just put stuff in one place on every system.
- FooBarWidget 14y ago
  And how does your point lead to the conclusion that installing such third-party software to /usr/local/whatever is a bad idea? I can just run 'ls /usr/local' to see a list of non-conforming software.
  - buster 14y ago
    I didn't say it's a bad idea, i said it's a matter of fact that software exists that runs in /opt/ and that sometimes there are reasons to do so. For example, a particular usecase is to have a specific mountpoint that holds shared binary and configuration in a cluster environment that can't be mixed with native applications and configuration files. Also sometimes you don't have the user rights to install in /usr or policy forbids to install 3rd party software in /usr. /opt is the usual way to go then.
  - lloeki 14y ago
    /usr/local is the tertiary hierarchy per the FHS, by this naming, there should be no whatever there other than bin/lib/shared/... just like on the primary and secondary hierarchies, whereas /opt is the wild wild west, often organised by software package (/opt/android-sdk), even with side by side versions (/opt/ree-2012.02), or by vendor (e.g /opt/oracle/java-7-sdk). This is merely a convention, not set into the 2.3 standard apart from the naming 'tertiary hierarchy' otherwise implying this, but it's nonetheless a widespread enough convention — notably in use by every single configure/make/make install (and more) source distribution out there, whose default PREFIX is /usr/local — that we can expect it to be standard behavior.
dredmorbius 14y ago
You can effect pretty much the same thing by symlinking /opt to /usr/local/opt/ Which is how I manage my systems. Similarly for /srv Remember: the filesystem hierarchy and your underlying storage don't have to correspond. There are other tricks which can be accomplished by union mounts or similar foolishness.
compay 14y ago
IIRC Unix systems were using "/opt" way before Linux was using "/usr/local". Cue the XKCD comic on competing standards: http://xkcd.com/927/ http://xkcd.com/927/
np422 14y ago
/opt is a tradition inherited from older commercial unixes like SCO, AT-T et al. Made popular in the later days mainly by solaris 2 heavy usage of /opt. Most vendor supplied software is by tradition installed in /opt, for which we should be forever thankful because most software vendor wouldn't recognize a properly packaged piece of software even if it jumped up and bit them in their arse. Oracle was in the early days installed in /u01 with data- and log-files spread out over separate disks with mountpoints normally named /u02,/u03 and so forth. It isn't uncommon that this naming convention still partially is used on oracle installations. Today oracle published a standard called Optimal Flexible Architecture (OFA) where all oracle products should be installed under a common top-level directory. The oracle universal installer isn't as horrible as it used to be but it isn't a well behaved rpm/dep installation either, at least it claims to have heard about LSB-directory structure even if it doesn't follow it very well.

/usr/local is meant to replicate /usr in the way that binaries go into /usr/local/bin, libraries into /usr/local/lib etc., but for software that isn’t managed by the package manager – at least that’s what it is used for nowadays. So a well-behaving software would happily go into /usr/local, whereas the ugly software things that want their own folder somewhere better go into /opt.

FooBarWidget 14y ago
And why is that distinction important? It seems a fairly arbitrary rule to me. What's the problem with dropping stuff in /usr/local/foo?
- e12e 14y ago
  It's not set in stone. I also prefer having packages with their own hierarchies under /opt, rather than /usr/local/<package> -- in general stuff under /usr/local should put their binaries in /usr/local/bin -- their manpages under /usr/local/share/man, headers and libraries in the corresponding places -- so that I don't have to mess with my PATH settings to be able to run a command, look up a man page or link against a library. Sometimes software isn't packaged for use on a posix-like system -- and then I might have to do some dancing to get it to work -- I usually prefer having such programs under /opt/<program-version>. I do have another folder under local: /usr/local/xstow -- so I can easily compile packages and manage different versions under /usr/local/xstow/package-x.y.z. http://xstow.sourceforge.net/ http://xstow.sourceforge.net/

buster 14y ago

Because, maybe, but only maybe, there might be software that is not split up into lib, bin, doc directories and that doesn't log into /var/log?! There actually is quite some software like that and sometimes it even has a technical reason. Especially some commercial and proprietary software that runs on Windows, HP-UX, SCO, AIX, Solaris and Linux tends to go the "easy way" of packaging and just put stuff in one place on every system.

FooBarWidget 14y ago
And how does your point lead to the conclusion that installing such third-party software to /usr/local/whatever is a bad idea? I can just run 'ls /usr/local' to see a list of non-conforming software.
- buster 14y ago
  I didn't say it's a bad idea, i said it's a matter of fact that software exists that runs in /opt/ and that sometimes there are reasons to do so. For example, a particular usecase is to have a specific mountpoint that holds shared binary and configuration in a cluster environment that can't be mixed with native applications and configuration files. Also sometimes you don't have the user rights to install in /usr or policy forbids to install 3rd party software in /usr. /opt is the usual way to go then.
- lloeki 14y ago
  /usr/local is the tertiary hierarchy per the FHS, by this naming, there should be no whatever there other than bin/lib/shared/... just like on the primary and secondary hierarchies, whereas /opt is the wild wild west, often organised by software package (/opt/android-sdk), even with side by side versions (/opt/ree-2012.02), or by vendor (e.g /opt/oracle/java-7-sdk). This is merely a convention, not set into the 2.3 standard apart from the naming 'tertiary hierarchy' otherwise implying this, but it's nonetheless a widespread enough convention — notably in use by every single configure/make/make install (and more) source distribution out there, whose default PREFIX is /usr/local — that we can expect it to be standard behavior.

dredmorbius 14y ago

You can effect pretty much the same thing by symlinking /opt to /usr/local/opt/ Which is how I manage my systems. Similarly for /srv Remember: the filesystem hierarchy and your underlying storage don't have to correspond. There are other tricks which can be accomplished by union mounts or similar foolishness.

compay 14y ago

IIRC Unix systems were using "/opt" way before Linux was using "/usr/local". Cue the XKCD comic on competing standards: http://xkcd.com/927/ http://xkcd.com/927/

np422 14y ago

/opt is a tradition inherited from older commercial unixes like SCO, AT-T et al. Made popular in the later days mainly by solaris 2 heavy usage of /opt. Most vendor supplied software is by tradition installed in /opt, for which we should be forever thankful because most software vendor wouldn't recognize a properly packaged piece of software even if it jumped up and bit them in their arse. Oracle was in the early days installed in /u01 with data- and log-files spread out over separate disks with mountpoints normally named /u02,/u03 and so forth. It isn't uncommon that this naming convention still partially is used on oracle installations. Today oracle published a standard called Optimal Flexible Architecture (OFA) where all oracle products should be installed under a common top-level directory. The oracle universal installer isn't as horrible as it used to be but it isn't a well behaved rpm/dep installation either, at least it claims to have heard about LSB-directory structure even if it doesn't follow it very well.