Robin Laing wrote:
Ah, this discussion shows that the question about where applications are installed isn't that easy to answer.
This is true, but it's not that complicated once you realize that the 'nature' of an install depends not on the software itself, but on the packager. It also helps to read the FHS carefully.
From the Filesystem Hierarchy Standards is states "Large software packages must not use a direct subdirectory under the /usr hierarchy."
I don't know about you, but I would claim OpenOffice is a large software package.
/usr/lib/openoffice is not a "direct subdirectory" of /usr.
/usr/openoffice would be illegat according to this rule.
As mentioned before, "Applications may use a single subdirectory under /usr/lib."
Now if you don't install an application during installation of the OS does it become an optional program? What about users wanting/needing the latest patch or feature upgrade? This can cause problems for the new users.
New users should stick with vendor-supplied or compatibly packaged software where possible. All software using the OSs own installation machanism and database (in our case rpm) can (and should) be installed under /usr.
Software using a third party installer may install under /opt.
Software compiled and installed by the end-user should go under /usr/local.
This is all generally a good thing, as a user can compile and install different versions of a package into /usr/local without disrupting the system-installed version or upsetting other system applications that may depend on it.
As the thread is also looking at included applications, this can increase headaches for those less experienced. I see an add-on or plugin that will increase my usage. It isn't supplied by Fedora or RH due to copyright or other reasons and that is acceptable. But there are no RPM's (that I can find) so I download the add-on and follow the installation instructions. The problem occurs when I cannot find the specific directories as they are different than the default application install (/opt/xxx or /usr/local) as stated in the documentation. I have come across this in the past.
If the application was installed using an installation system like rpm, ask the system where it installed the files. I find 'rpm -ql package' very useful in these circumstances. Additionally, the packager -should- have adjusted the installed documentation to reflect the actual location of binaries and configuration files.
If you want to compile-in an add-on, you generally have two options as an end user:
1) Compile the patched source yourself and install under /usr/local.
2) Use the src rpm and the patch to create your own patched rpm (change the subversion and add a personal tag as appropriate) and update. In this case it's now your responsibility to fix any new documentation and make sure your changes don't break the system.
Actually, even in case #1 the location is often changed from the default. I always configure packages with PREFIX=/usr/local/packagename because it makes it easier to keep files straight and to know what package something belongs to. Usually the manpages are adjusted appropriately for me.
Online documentation does have the drawback of not knowing where a particular packager has chosen to install something, and will usually just refer to their most common default location, usually with a note that you should adjust based on where it really is.
I always thought that the idea of standards is to make sure things work together with no headaches or problems with a disregard to distribution. I thought that was why the Linux Standards comities were created.
"No headaches or problems" is a pretty tall order. I don't think any OS manufacturer has fully managed to achieve that. What the filesystem standards do (and do successfully) is provide a consistant layout with files and packages in reasonably well-defined places based on what they do and who created them.
