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 <h...@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@lists.macosforge.org > > http://lists.macosforge.org/mailman/listinfo.cgi/macports-users _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users