<div dir="ltr"><div><div>My trick to having a harmonious multi-package manager system is to have a hierarchy, in which MacPorts is where the majority of packages are built, and the others are only used to fill in the gaps.<br>
<br></div><div>For example, Free Pascal. MacPorts doesn't have it. I could spend the time creating a port, but I want it now. So, I used Fink to install it. Problem solved.<br></div><div><br></div>Also key is to make sure that MacPorts comes first in the $PATH, $MANPATH, and $INFOPATH.<br>
<br></div>I haven't had any problems, but another person's mileage may vary.<br><div class="gmail_extra"><br></div><div class="gmail_extra">Art<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 11, 2014 at 2:45 PM, Brandon Allbery <span dir="ltr"><<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 11, 2014 at 4:12 PM, Art McGee <span dir="ltr"><<a href="mailto:amcgee@gmail.com" target="_blank">amcgee@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
They keep their environment segregated from the rest of the system, and because of this, even though any MacPorts admin will strongly and vehemently advise against even trying it, they can work in concert with each other.</blockquote>
</div><br>Mostly. What you're missing is that configure scripts are pernicious, and even with the most careful vetting and editing they will occasionally glom onto stuff under /sw/lib and incorporate it into a MacPorts build, leading to bizarre problems when you upgrade Fink later. (Yes, I've seen this happen.) Note that it can't usually happen in the other direction unless you're in the unusual habit of building Fink stuff from source instead of installing the prebuilt debs. (But it's also possible for stuff using dynamically loaded libraries to slip its leash and spot libs under /opt/local/lib, with similarly bizarre errors as the result.)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Both of these are more likely if you're also committing another cardinal sin, namely setting $DYLD_LIBRARY_PATH or $DYLD_FALLBACK_LIBRARY_PATH. But then, the former has the strong potential to break your entire system in "interesting" ways, and the latter is only a little bit safer --- so just don't do it except as a workaround for broken programs, and in that case use a script wrapper around those programs rather than risking breaking everything in order to make it happy.<span class="HOEnZb"><font color="#888888"><br clear="all">
<div><br></div>-- <br><div dir="ltr"><div>brandon s allbery kf8nh sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a> <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div>
<div>unix, openafs, kerberos, infrastructure, xmonad <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div>
</font></span></div></div>
</blockquote></div><br></div></div>