4 ms·

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

by buster 13y 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 13y 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 13y 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 13y 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.

by buster 13y ago

FooBarWidget 13y 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 13y 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 13y 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.