Just to clear things up a little: With SL6 and earlier, we had /usr/local 
be a symlink into afs space.  With SL7, we changed it so that the 
subdirectories (bin, etc, lib, lib64, include, sbin) are symlinks.  This 
avoided some problems that came up with installation, but we still have 
trouble when there is an update to the filesystem package.

Steve Gaarder
System Administrator, Dept of Mathematics
Cornell University, Ithaca, NY, USA
[log in to unmask]

On Sat, 14 Nov 2015, Nico Kadel-Garcia wrote:

> On Sat, Nov 14, 2015 at 1:56 AM, Benjamin Lefoul
> <[log in to unmask]> wrote:
>>> Be clear that replacing /usr/local with a symlink in the form you describe is *not* compliant with the FSH.
>>
>> Actually it is, in both FHS version 2.3 and version 3.0.
>>
>> http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s02.html
>>
>> The following directories, or symbolic links to directories, are required in /usr.
>> Directory       Description
>> bin     Most user commands
>> lib     Libraries
>> local   Local hierarchy (empty after main installation)
>> sbin    Non-vital system binaries
>> share   Architecture-independent data
>
> Wow, thank you, good point, thanks for the correction, I was looking
> further down the documentation at the subdirectories.
>
> I'd written:
>> A symlink form /usr/local to a read-only AFS space is *not* the same
>> thing as symlinks for /usr/local/bin, /usr/local/etc,
>> /usr/local/share, /usr/local/lib, etc. Be clear that replacing
>> /usr/local with a symlink in the form you describe is *not* compliant
>> with the FSH. Not that it's not useful in your environment, but just
>> so you appreciate that you may have issues with core packages such as
>> the "filesystem" package.
>