rds :: graphikos

[ home | photos | gallery | scheme | notes | blog | facebook | twitter | youtube | last.fm | myspace | del.icio.us | EverythingHerePlus ]

Utilizing an Alternative to /usr/local on OSX

Like anyone with prior Unix experience, I began porting applications to OSX. For the most part that meant functional language implementations, particularly Scheme variants. However, there were essential tools like Texinfo and Lynx to install. Occasional curiosities like Bochs as well. Just about everything compiled and built from source installs in /usr/local. Many items from various package managers went there as well. Soon I noticed that the directory was swelling with items. Worse still, was the fact that many items were duplicate as they didn't overwrite older versions. The unmanageability of this directory finally made me sympathize with some of the reasons the Fink Project cite for not using /usr/local although I still don't agree with their choice of placing a directory on the root level of the system. The situation was becoming worse for me as I do a lot of testing to see if something compiles, installs and runs correctly, but have no intentions of using it afterwards.

I needed to have a place to install items that wouldn't be at the mercy of Apple updates and would be easier to manage. I also wanted a directory that if necessary, I could clean out without worrying about deleting essential items. Rather than reinvent the wheel, I turned to the most natural directory MacOSX offers for such requirements: /Users/Shared. This directory was an excellent choice as its intention was for sharing among various user accounts, and the permissions should work correctly. It is consistent on all MacOSX installations, making it a better choice than using a directory in a user account. Further, it doesn't require administrative permissions on make install. The only real issue I had with /Users/Shared is as with many directories in MacOSX, Apple chose to use mixed case naming, a bizarre violation of common Unix convention. Nevertheless, I found that the choice has worked out well.

Another reason why this is a good way to manage local installs is avoiding name collisions. I installed the GNU fileutils, because I got tired of missing options in Apple's antiquated versions of common userland utilities in versions of OS X prior to 10.3. For example the -h option for df and ls -l calls provides readable file sizes for any modern BSD or Linux implementation. Installing fileutils, and having /Users/Shared/bin and /Users/Shared/sbin first in PATH allows the newer versions to run without overwriting default utilities. To use the Apple supplied versions, remove the /Users/Shared items from the PATH. Adding the directories is described below.

The first step was to create the common directories a local site needs. Essentially these are the same as those found in a typical /usr/local and are listed below. After the directories are created, all that is needed to utilize them when installing source based packages is to use the prefix option on configure time. Nearly every configure script provides this option, type ./configure --help | grep prefix in the source directory of a package to check. Type the following at configure.

./configure --prefix=/Users/Shared # add other switches here

When make install is executed, the installation will occur in the directory specified at configure. The only other thing to do is add /Users/Shared/bin and /Users/Shared/sbin to the PATH environment variable. This is best done in the ~/.cshrc file so that it updates every time a new shell is spawned. Although I have found older versions (10.2.3/4) sometimes don't read ~/.cshrc, this is overcome by typing exec tcsh at the prompt. 10.2.5 and later don't exhibit this issue.

setenv PATH /Users/Shared/sbin:${PATH}
setenv PATH /Users/Shared/bin:${PATH}

Directories Created in /Users/Shared



UNIX Porting Guide, Apple Computer, Inc. 2002