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
gaar...@math.cornell.edu
On Sat, 14 Nov 2015, Nico Kadel-Garcia wrote:
On Sat, Nov 14, 2015 at 1:56 AM, Benjamin Lefoul
<benjamin.lef...@nwise.se> 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.
