Hi, > On Apr 04 11:26:14, Jeremy Lavergne wrote: >> /usr/local is horrible because it takes precedence >> over everything else on your system > > Yes, it takes precedence. That's the point: to have a place where > things are supposed to be installed. Why does it make /usr/local "horrible"? > How would that be less "horrible" if it was any other directory? > >> This means incorrect libraries and headers >> that magically find their way in there via other installers >> will be used instead of the software that was actually intended. > > Whoa, stop right there. This paragraph makes no argument against /usr/local, > it's just dissing it with meanlessly negative adjectives. > > (*) What "incorrect libraries and headers"? > The headers and libraries I install under /usr/local (or anywhere else, > for that matter) manually (or any other way, for that matter) > are no more or less "correct" than those installed by macports > (or any other installer, for that matter). > > (*) How exactly do they "magically find their way" into /usr/local? > The user installs it there! > > (*) Yes, the stuff under /usr/local will be used then. > That's why the user installed it in there; because > that's what he "actually intended".
I think you are missing an important point. MacPorts has a hard enough time making sure its own internal ecosystem is consistent and works with itself. Making sure all the various versions of the packages MacPorts has available are consistent and compatible with themselves is a massive job. Just because you have installed something in /usr/local, and think it is the version you want used, does *not* mean that version is compatible with what MacPorts needs, up to date, or plain working at all. Macports tends to keep itself up to date, more or less, but it has absolutely no way to know whether *you* are doing the same for what you put in /usr/local More over, there are some packages MacPorts provides that conflict with each other. You *cannot* have both installed at once. MacPorts provides both, so the user can decide. Given all of this, it is I think unreasonable to expect MacPorts to be compatible with whatever it happens to find in /usr/local. It *has* to have complete control over what it uses, in order to be able to have some chance of making sure things work OK. Given the way, as others have described, /usr/local finds its way into various compilers and utilities, whether you want it to or not, the only approach I can see MacPorts taking is leaving it up to the user. If a problem occurs, and that problem is due to /usr/local, it is I think completely reasonable for the response to be "try again without whatever you have in /usr/local". cheers Chris
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
