Using /usr/local

"Today’s UNIX and UNIX-like systems (such as Mac OS X, Linux, FreeBSD, Solaris, etc.) allow you to create a special place in the filesystem where you can compile and install your own software independent of and without affecting the rest of the system."<p>Yes, that is called "/opt", not /usr/local. /usr/local is for local extensions to the operating system itself, not applications.

&#62; It turns out that the update has actually overwritten the Ruby binary she’s compiled with a different version, and her software no longer works. &#62; &#62; This could have been avoided if she’d installed the Ruby binary in a safer place, and set her shell and her software to use that binary.<p>and then every time you try to work with other ruby-related software, it either picks up the new version in /usr/local or the old version in /usr or some random version in /opt/local that macports installed, and you may not be sure which. this problem gets much worse when you are dealing with shared libraries like graphics libraries. the autoconf junk may help by allowing you to specify something like "./configure --with-jpeg=/usr/local ..." but sometimes you have to override LDFLAGS and you're suddenly wasting so much time just trying to get all this stuff to work.<p>3rd party port/package systems for mac os just made the problem worse by forcing you to install duplicate copies of everything that comes with mac os because of package dependencies. i think a better solution would be to only have one version of the software on the system at a time. if macports wants to upgrade your ruby, make it delete everything in /usr/lib/ruby or setup symlinks to the new version in /usr/local/lib/ruby.

A few years of systems have given me a really good way for handling this problem (other than the obvious bit of just using whatever packaging system the OS provides). I use /opt rather than /usr/local, but you can do either.<p>Build all your packages into /opt/package-version, and set up a symlink from /opt/package to /opt/package-version for whatever you want the default version to be. As an example, Ruby 1.8.7 goes into /opt/ruby-1.8.7, and /opt/ruby points to this directory.<p>The only disadvantage is you need to add each bin/ directory into your path, which will be a problem if you install hundreds of applications in this fashion.<p>On the other hand, being able to do in-place upgrade and rollback almost instantly (just re-point the symlink) is a big, big win in a production environment. Plus, because everything is located in one place, you can readily move your /opt/app-version directory to other systems.

I'm surprised no one's mentioned the utility "stow". It lets you install things to their own /usr/local-style hierarchy and will symlink all the files for you. That way you can easily remove something after you've deleted the source directory.

Readers of this article might also be interested in Fink: a package manager for OS X, based on dpkg and apt from Debian.<p>About Fink: <a href="http://www.finkproject.org/about.php" rel="nofollow">http://www.finkproject.org/about.php</a><p>Guide to building your own packages: <a href="http://www.finkproject.org/doc/quick-start-pkg/index.php" rel="nofollow">http://www.finkproject.org/doc/quick-start-pkg/index.php</a>

See also hier(7) (<a href="http://www.openbsd.org/cgi-bin/man.cgi?query=hier" rel="nofollow">http://www.openbsd.org/cgi-bin/man.cgi?query=hier</a>). That's the OpenBSD man page, something comparable will probably be present on other Unices. (OpenBSD's pkg system installs all non-base packages in /usr/local/ , fwiw.)

This is a great article. It's been around for a while but it completely changed how I build projects on my Mac.