I have a mostly theoretical question about a LFHS recommendation.

According to the Linux File-system Hierarchy Standard, programs you install yourself, such as tarball installations should use the /usr/local directory as the installation base. This I understand, but they recommend that the /usr/local directory be a static / shared directory.

from the FHS:
If /usr/local is shareable amongst a group of hosts, where would the base installation directory be for the local host itself?

Ok:

machine A is exporting its /usr/local
machine B is mounting machine A's export

There's no rule that says machine B must mount machine A's /usr/local export at machine B's /usr/local filesystem. Mount it somewhere else, and modify the path appropriately.

machine A retains the "local" sense of /usr/local even though it is exported
machine B retains an explicit /usr/local of it's own, while accessing machine A's /usr/local at some other point in the filesystem.

Is that what you were getting at, or did I miss the question?

The main purpose of this directory is that it persists between upgrades, and isn't part of the install. The word local to me implies that it is local to each machine. Perhaps the true sense is that it is local to the site and I'm just looking at it wrong.

I realize that if you want a directory local to each machine, you could make your own.

I'm not quite sure I follow you. What is the complication by viewing "local" to mean specific to that machine? I'm looking for an example of the conflict you're getting at to help me understand where you're coming from.

Suppose you install a program from a tarball with the usual, configure, make, make install steps.
The configure phase will analyse how the program and libraries will be compiled. A system with an AMD chip may have a library compiled differently then one of the other hosts with dual-xeon's for instance. I guess the answer is to only share the /usr/local directories between hosts with similar hardware configurations.

Mainly, my preconception was that the /usr hierarchy would be shared, and /usr/local would contain items specific to the host. Either programs or libraries that are compiled to take advantage of specific hardware, or programs that the root user on that host would install due to personal preferences.

Perhaps, I just haven't worked in an environment with a large number of computers administered centrally, were programs are never installed on the local host, but on a central server.

The naming may also be due to historic reasons, and the usage may have changed over time.

Maybe my question should be, if your system has a shared /usr/local hierarchy, where is the standard place for installing programs that are local to an individual host, or does the LFHS standard recommend against this because of the administrative problems this would cause allowing programs installed on individual hosts.

I haven't worked in a large environment like you describe either. So we're both winging it sort of. My perspective on the /usr/local thing was from the idea of having specialized machines for a given task. Have one machine handle database management for customer orders for instance. Have another handle web serving or whatever. Those specialized machines don't necessarily export their /usr/local as a means to become an application server. They might be exported to provide configuration information or just pure data; allowing the client machines read access to the database, straight html file access without having to go through a browser, or other types of things. The argument could be made that why not just export the configuration or data files rather than the whole /usr/local filesystem. You could do that, but it might get messy if data is not stored in a nice filesystem hierarchy, or if the machine is set up to handle 2 or 3 specialized roles (you'd need one export for each set of data).

You're right about the hardware difference for applications though. My only thought about that would be that it isn't meant to share applications in that way. At least, not without a wrapper. Have the exporting machine provide a shell/perl/python script that sends a custom request from the client to the specialized machine to run program X.

For myself the matter is purely academic. I just need to know that the programs I install will go into /usr or /usr/local, and that an upgrade will not touch /usr/local. I can see how a system with 50 or 100 homogeneous hosts sharing /usr and /usr/local would be much easier to administer. Performing a security upgrade on one would take care of the others for instance. It seems to me that the LFHS had to balance the practices of large commercial sites, what the software developers are doing, the layouts the distributions use, and the single end user.