[ale] File System for Newbs

[Michael B. Trausch]

On Tue, 28 Jul 2009, Jim Kinney wrote:

> /usr/local is the path prefix to use to for applications compiled by
> the sysadmin that use shared libs such as /usr/lib/foo. Further,
> /usr/local/lib is (usually) in the ld_conf_so path structure so
> sysadmin compiled libs will be available system-wide. There's a reason
> that /usr/local has a structure similar to /.  Locally compiled (i.e.
> not built using distro tools for package manager - apt, rpm, etc)
> binaries should _NEVER_ be placed in /bin, /usr/bin, /sbin, /usr/sbin,
> /lib, /usr/lib .

Absolutely.  I am pretty sure that's why (at least for the GNU build system) 
the default PREFIX is /usr/local; Debian will specify each directory manually, 
other systems will say --prefix=/usr when installing packages.  They all will 
change the install target using DEST (DIST? I don't recall...) so that they 
can create an archive for later installation into the previously-specified 
directories.

Having only really learned the GNU build system recently, it suprises me just 
how amazingly flexible it is.  It uses lots of very old tools to get things 
done, and it is amazingly hard to learn initially, but once you understand the 
underpinnings of it---really understand them---it starts to become very easy 
to use.  I'm beginning to think that the premise of GNU software is that they 
intentionally trade ease-of-learning for ease-of-use once learned.  And that's 
fine for me, though it took me years to "get" it.

The way that they built it all, though, makes it _extremely_ easy for one to 
install software just wherever fits them.  You can install a package from 
source in /Applications/${NAME}-${VERSION} if you want, and symlink things 
into /usr/local or /opt.  Or you can have a package manager that takes a 
totally different approach.  And because of the near-ubiquitousness of the GNU 
build system, this doesn't require a package manager to maintain diffs to 
makefiles just to be able to take such an approach.  It really is very nice.

> /opt is a place to put statically compiled applications that use
> library paths relative to the launcher binary. Applications like this
> are oracle and other binary-only packages that are usually shipped as
> tarball. The exception is that stupid semi-scripting language called
> java. It goes in /usr/java or /usr/local/java (/usr/local/trashcan
> would be better - snarl).

That's a nice way to distinguish things, though I don't do it that way.

I use the /opt tree for things that I want isolated.  For example, my phone 
system:  It keeps not only its binaries in /opt/freeswitch, but it's 
configuration (/opt/freeswitch/conf), vms (/opt/freeswitch/storage/voicemail), 
and so forth.  I use /opt for things that I'd like to be able to delete simply 
by doing "rm -Rf /opt/${PROG_NAME}-${PROG_VER}".  Oh, and I do maintain 
symlinks to switch between versions for most things in /opt.  I have, for 
example, /opt/bzr which (currently) points to /opt/bzr-1.17 on my server. 
That way, I only have to put /opt/${PROG_NAME}/bin:/opt/${PROG_NAME}/sbin in 
my path and it works, and I can switch between versions quite easily.

I do think that /opt should be the _only_ place that binary-only software 
lives, with symlinks into wherever it wants to be.  However, lots of 
binary-only software (such as the Adobe software) seems to ignore that.  Flash 
would be best in /opt/adobe/flash-${VERSION} IMHO, with the plugin symlinked 
into the Mozilla directory.

> The /usr/*/share/applications is the desktop launcher area. Under _NO_
> circumstances should anything but a desktop file be placed there. See
> other desktop files for the format.

Absolutely.  And, I have to say, I'm _really_ happy that FreeDesktop came to 
be, and that people actually follow those standards...

 	--- Mike