<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="color:rgb(0,0,0);font-size:12.8000001907349px">Yes, that is what I was saying, where, again, by "git project", you mean "some software project that just so happens to do its development in a git repository". The use of git is incidental to the problem.</span></blockquote><div><br></div><div>Heh, I think I finally see where we are talking pass one another. I wholeheartedly agree with this: "<span style="color:rgb(0,0,0);font-size:12.8000001907349px">some software project that just so happens to do its development in a git repository."</span></div><div><br></div><div><span style="color:rgb(0,0,0);font-size:12.8000001907349px">That said, I don't think it's merely incidental. After all, git is, in a sense, part of the Macports ecosystem by virtue of a version of it being hosted by Macports. Is there not a policy about hosting ports -- whether version control or other types of software distribution mechanisms -- that may distribute projects that ultimately harm a Macports installation? </span></div><div><span style="color:rgb(0,0,0);font-size:12.8000001907349px"><br></span></div><div><span style="color:rgb(0,0,0);font-size:12.8000001907349px">My reason for bringing up "/opt/local" was because I was wondering if there was a chance that the makefile of some git project (or any other project management system!) might instruct it (implicitly or explicitly) to install under /opt/local. And if so, how could this be systematically avoided.</span></div><div><span style="color:rgb(0,0,0);font-size:12.8000001907349px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="color:rgb(0,0,0);font-size:12.8000001907349px">I was assuming that you had already resolved the original problem from the ticket referenced in the subject line, by removing the now-broken symlink(s) "port select wxwidgets" had created on your system (if you haven't done that yet, then you should do that now), and were encountering a new problem specific to this software you downloaded and built.</span></blockquote><div><br></div><div><span style="color:rgb(0,0,0);font-size:12.8000001907349px">You assumed correctly! Those aforementioned instructions worked, though only in concert with uninstalling libraries installed by certain git projects. I carried on though because I had assumed that getting rid of that symlink broke wxmaxima. Well, at least the ability for it to be summoned directly from command line.</span></div><div><span style="color:rgb(0,0,0);font-size:12.8000001907349px"><br></span></div><div><span style="color:rgb(0,0,0);font-size:12.8000001907349px">If there really is no practical or meaningful way for this to move forward, I'm prepared to drop my concerns!</span></div><div><span style="color:rgb(0,0,0);font-size:12.8000001907349px"><br></span></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>Christopher D. Ramos<br><br><a href="https://www.linkedin.com/in/chrisdavidramospaxperscientiam" target="_blank">LinkedIn</a></div><div><br><a href="http://www.paxperscientiam.com" target="_blank">Pax Per Scientiam</a><br><br></div><a href="http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2EAD11447DF2D80A" target="_blank">Public Key</a><div><br></div></div></div></div>
<br><div class="gmail_quote">On Tue, Jun 23, 2015 at 6:08 PM, Ryan Schmidt <span dir="ltr"><<a href="mailto:ryandesign@macports.org" target="_blank">ryandesign@macports.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On Jun 23, 2015, at 4:13 PM, Christopher David Ramos wrote:<br>
><br>
><br>
>><br>
>> There is no inherent conflict between MacPorts and any given<br>
>> software downloaded with git. Rather, there is (apparently, from what<br>
>> you've told us) a conflict between MacPorts and the specific software<br>
>> you downloaded with git, but that conflict would have been present<br>
>> regardless of how you downloaded the software; it has nothing at all<br>
>> to do with git. Git is just a program that lets you download things.<br>
>> It has no knowledge of whether those things you download are going<br>
>> to conflict with other parts of your system.<br>
><br>
> You are paraphrasing what I just said.<br>
<br>
</span>Not intentionally.<br>
<span class=""><br>
><br>
> My understanding is that Macport ports install there own libraries under<br>
> the path prefix "/opt/local/" so as to prevent conflicts with and<br>
> reliance out of date Apple libraries.<br>
<br>
</span>Well yes. I mean, MacPorts needs to install itself *somewhere*, some prefix. Bad choices for prefix would be /usr (that's where Apple installs stuff) and /usr/local (that's where compilers look for dependencies by default, and is where users expect to be able to install software manually). A good choice is therefore anywhere else. We chose /opt/local.<br>
<span class=""><br>
> Are you saying that it was only a<br>
> fluke that a git project would have built files into Macports created<br>
> directories?<br>
<br>
</span>Yes, that is what I was saying, where, again, by "git project", you mean "some software project that just so happens to do its development in a git repository". The use of git is incidental to the problem.<br>
<br>
<br>
I was assuming that you had already resolved the original problem from the ticket referenced in the subject line, by removing the now-broken symlink(s) "port select wxwidgets" had created on your system (if you haven't done that yet, then you should do that now), and were encountering a new problem specific to this software you downloaded and built.<br>
<br>
<br>
</blockquote></div><br></div>