Yes, that is called "/opt", not /usr/local. /usr/local is for local extensions to the operating system itself, not applications.
But, folks really ought not be encouraging this sort of thing, in general. Unless you really know you need some specific version of software, and why, you should probably be using the OS-provided packages, which are better tested (so they're generally more reliable), better supported (so you can complain to someone when you run into a problem), and more widely used (so you can find people talking about your specific version when you hit up Google for advice).
Anyway, I agree. /opt is the socially acceptable place to put random crap on a system.
/usr/local/ executables, libraries, etc. not included by the basic operating system
'/opt' is not documented by hier(7) on FreeBSD, Mac OS X, or OpenBSD.
The only way I feel comfortable compiling software into my system because I KNOW I can delete it by just removing the directory created inside /opt.
The only tricky part is making sure your compiled binaries in /opt/*/bin are in your executable path.
/usr for stuff installed by apt-get.
/usr/local for stuff I install with "./configure && make && make install" or similar commands.
/opt for self-contained application bundles.
Wikipedia (http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard) says it's for "Tertiary hierarchy for local data, specific to this host."
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.
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.
On the other, you decry 3rd party port/package systems because they use their own entirely independent dependency hierarchy for the purpose of wholly avoiding incompatibility issues.
Then you recommend that 3rd party port/package systems actually delete operating system managed components and replace them with their own.
This position is, at best, inconsistent.
and that is why i gave up trying to use mac os as my desktop. there was no proper way to install 3rd party software that dealt with conflicting versions.
if macports or some other package solution could get it right, then articles like this one would be irrelevant and users could just do something simple like "<some utility> install ruby", get a new ruby installed and have the old built-in version disabled. until something like that happens, you are going to run into issues where some software picks up one version and something else picks up another. relying on a properly set $PATH is not a solution.
Any other approach will directly interfere with other operating system components and lead to exactly the bizarre failure cases you are reporting.
Yes,I've lost hundreds of hours to this kind of thing.
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.
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.
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.
No need for package managers that do who knows what to your system.
The one exception is for shared libraries, which I build to /usr/local. That way 'make' can find them easily without fiddling with LDPATH.
I don't see the need or point for /opt. I guess I'm socially unacceptable?
Guide to building your own packages:
Fink downloads pre-built binaries, but AFAIR, it can build from source, too. It also has a GUI interface.
That's about all the insight I can provide.