/usr/local question

[Jan Stary]

On Apr 05 10:49:01, Dominik Reichardt wrote:
> As far as I can tell, /usr in PATH is being honored
> opposed to /usr/local being picked up automatically.

I don't know how "honored" differs from "being picked up",
but PATH has nothing to do with this.


> Am 05.04.2012 um 10:25 schrieb Jan Stary <hans at stare.cz>:
> 
> > On Apr 05 09:00:44, Jan Stary wrote:
> >> However, if a given port silently picks up something
> >> incompatible in /usr/local, if might fail and often will.
> >> 
> >> Having macports isolated in /opt/local DID NOT save you from this.
> >> Removing /usr/local is what did.
> > 
> > One more point to this: what if the colliding, incompatible
> > software that stops a given port from building successfully
> > is not found under /usr/local, but in /usr, which is
> > even more prominently recognized by various build tools.
> > 
> > That's not made up: /usr/lib/libssl.*
> > Say the port requires a newer version of openssl
> > than what /usr/lib/libssl.* provides.
> > 
> > That's the same situation as with a port not building
> > because some incompatbile software was found and
> > picked up from /usr/local; except now it is /usr.
> > 
> > What is the advice here?
> > Ceratinly not to temporarily rename /usr.
> > 
> > I argue that temporarily removing /usr/local is just as bad,
> > and the problem of a port picking bad stuff from /usr/local
> > is that given port's defect that needs to be fixed before
> > the port gets built; not a reason to remove /usr/local.
> > 
> > (Which doesn't change the fact that /opt/local is a better prefix,
> > I am over that already.)
> > 
> > _______________________________________________
> > macports-users mailing list
> > macports-users at lists.macosforge.org
> > http://lists.macosforge.org/mailman/listinfo.cgi/macports-users