On Fri, Nov 13, 2015 at 7:28 AM, Nico Kadel-Garcia <nka...@gmail.com> wrote: > On Thu, Oct 29, 2015 at 2:17 PM, Steve Gaarder <gaar...@math.cornell.edu> > wrote: >> I always thought that /usr/local was defined to be an area left alone by the >> operating system. For many years, we have made it a symlink to a read-only >> directory in AFS space. This has worked fine - until now. When I tried to >> update the "filesystem" package, it failed because it tried to do chmods on >> (at least) /usr/local/bin and /usr/local/etc. Why is it doing this? Is >> /usr/local no longer truly local?
Sorry, that was my own fault, Now I have my coffee. The /usr/local/ directories are part of the File System Hierarchy, at http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY The particular stanza you want to review is below: Requirements The following directories, or symbolic links to directories, must be in /usr/local DirectoryDescription bin Local binaries etc Host-specific system configuration for local binaries games Local game binaries include Local C header files etc., etc. So, yes, it looks like upstream is following the File System Hierarchy. To play nicely with it, you should ideally, replace the subdirectories in /usr/local/ with individual symlinks. And you've my sympathies: I just spent some work dealing with systems where someone had replaced "/opt" with a symlink to "/usr/local" and not documented why anywhere, and seriously broke new software that expected the SELinux privileges it had set for commercial software in "/opt" to be useable.
