/usr/local question

[Jan Stary]

> I agree now that /usr/local is on fact a bad choice.
> What I find cnfusing or unclear is the reasoning about it
> in the the FAQ.
> 
> The most prominent reason given to me yesterday for not having
> /usr/local as a default prefix was that people will stupidly
> rewrite the stuff in there by blindly clicking through third-party
> installers. That for example is not mentioned in the FAQ at all.

> I will try to come up with a better reformulation based
> on what people have explained to me here.


OK, here is what I propose as a relacement/extension of FAQ#defaultprefix.
Does this correctly describe the reasoning that was kindly explained
to me in the previous discussion? Obviously, I would like this OK'd here
before I mangle the wiki.

(The XXX is where my English fails me. Could a native speaker
put the right verb in please that seems to slip my mind?)


* Why is /opt/local the default install location for MacPorts?

Traditionally, the place to install third party software on many UNIX systems
is /usr/local. However, having macports under /usr/local would be error-prone.
Many other software packages and packaging systems install in there, and
would accidentaly overwrite what macports has installed, or vice versa.
While this could be XXXed off as the user's own error, it is a fact that
users click through installers blindly, and consequently collisions under
/usr/local (and other prominent directories) happen very often.
Macports doesn't want to be a victim of that, and /opt/local provides
the splendid isolation - as would any other dedicated directory, of course.
Also, /usr/local is traditionally reserved for the given system's admin
to install local tools; macports doesn't want to stomp on that either.

(For the same reasons, fink uses /sw as its prefix.)


* So with macports under /opt/local I can use /usr/local freely?

No, not entirely. Even with macports living elsewhere, /usr/local
can still interfere. Some software (especially the GNU auto* tools
and gcc) looks into /usr/local for external headers, libraries,
and binaries. Ceratin ports might (and do) fail to build because
during their build something incompatible is found and picked up
from /usr/local. Good ports avoid this by explicitly specifying
--with-libfoo=/opt/local/lib/ or explicitly disabling all such
possible dependencies altogehter with --disable-foo or --without-bar,
but not all ports are able to do that.
In some cases, it might even be necessary to
temporarily make /usr/local disappear entirely for a given port
to build successfully. Obviously this wouldn't be possible if
macports itself lived under /usr/local.

(And a third which I don't expect to be let through:

* So in order to build a given broken port with macports,
  you advice me to remove /usr/local altogether, thus
  crippling my system for the duration of the build?

Sadly, yes.)