What we have done for the last 25 years on Unix and Linux systems to avoid 
this problem.
On a separate disk we put /home, /usr/local, /opt to keep the OS install sysem 
from rewriting these directories.  
There is also a /co-lib disk that we keep all data sheets and parts info etc   
In a manufacturing environment this is real help.

We add these to the users PATH and everything works out pretty well.  They can 
easily find information and added sw.   It it doesn't run correctly we then 
have get a new version a crude way of doing things but it works.

Above all else run a couple of back ups and keep on offsite.  Our insurance 
agent kept a back of system on a separate box.   The theirves stold it all 
and the only thing that saved him was we had upgraded his system a week 
before and the old disks were still on the shelf.
So without the orig. disks a cloud back up may not be a solution.

Larry Linder

On Friday November 13 2015 7:36 am, Nico Kadel-Garcia wrote:
> On Fri, Nov 13, 2015 at 7:28 AM, Nico Kadel-Garcia <[log in to unmask]> wrote:
> > On Thu, Oct 29, 2015 at 2:17 PM, Steve Gaarder <[log in to unmask]> 
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.