RedHat, Fedora future?

[Bevan C. Bennett]

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.