| 54 | | |
| 55 | | `/opt/local` was chosen so as to avoid stomping on other various installations (e.g. fink uses `/sw` to do the same); `/usr/local` is not a viable choice for several reasons: |
| 56 | | 1. Some software (especially auto* tools from Gnu) look in `/usr/local` as a default location, which means MacPorts can't be easily isolated when needed |
| 57 | | 2. `/usr/local` is usually reserved for the given system's admin to install items local to that system, and tends to be a bad choice to have taken over by a non-system port system |
| 58 | | 3. gcc considers `/usr/local` to be a standard system directory, causing (at least) the include directory to be unable to appear early in the list of include directories, and hence causing MacPorts-installed items to be difficult to use properly for items which need them (where another version is installed elsewhere, like `/usr/X11R6`) |
| 59 | | |
| | 54 | |
| | 55 | Traditionally, the place to install third party software on many UNIX systems is `/usr/local`. |
| | 56 | However, having macports under `/usr/local` would be error-prone for precisely that reason. |
| | 57 | Many other software packages and packaging systems install into `/usr/local`, |
| | 58 | and could accidentaly overwrite what macports has installed, or vice versa. |
| | 59 | |
| | 60 | While this could be dismissed as the user's own error, it is a fact that |
| | 61 | people click through installers blindly, and consequently collisions under |
| | 62 | `/usr/local` (and other prominent directories) happen very often. |
| | 63 | Macports doesn't want to be a victim of that, and `/opt/local` provides |
| | 64 | the splendid isolation (as would any other dedicated directory, of course). |
| | 65 | |
| | 66 | Also, `/usr/local` traditionally contains the given system's local admin tools; |
| | 67 | macports doesn't want to stomp on that either. |
| | 68 | |
| | 69 | (For the same reasons, fink uses `/sw` as its prefix.) |
| | 70 | |
| | 71 | === So with macports under /opt/local I can use /usr/local freely? === #usrlocal |
| | 72 | |
| | 73 | No, not entirely. Even with macports living elsewhere, `/usr/local` can still interfere. |
| | 74 | Some software (especially the GNU auto* tools and gcc) looks into `/usr/local` for external headers, libraries, and binaries. Certain ports might (and do) fail to build because during their build something incompatible is found and picked up |
| | 75 | from `/usr/local`. Good ports avoid this by explicitly specifying `--with-libfoo=/opt/local/lib/` or explicitly disabling all such possible dependencies altogether with `--disable-foo` or `--without-bar` but not all ports are able to do that. |
| | 76 | |
| | 77 | If you ask on a macports mailing list about a port failing to build because it chokes on something |
| | 78 | that it found and picked up in `/usr/local` you will probably be adviced to temporarily rename |
| | 79 | `/usr/local` to make it disappear entirely for the duration of the build. |
| | 80 | Obviously, this wouldn't be possible to do if macports itself lived under `/usr/local`. |
| | 81 | |
