<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Sat, Jan 18, 2020 at 3:20 AM Mojca Miklavec <<a href="mailto:mojca@macports.org">mojca@macports.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Fri, 17 Jan 2020 at 23:44, Christopher Jones<br>
<<a href="mailto:jonesc@hep.phy.cam.ac.uk" target="_blank">jonesc@hep.phy.cam.ac.uk</a>> wrote:<br>
> On 17 Jan 2020, at 10:36 pm, Dave Allured - NOAA Affiliate via macports-users <<a href="mailto:macports-users@lists.macports.org" target="_blank">macports-users@lists.macports.org</a>> wrote:<br>
><br>
> Chris, thanks for the quick reply.  You are correct, a private macports installation would enable testing ports without special privilege.  Actually I have already done this many times for testing and debugging other cases.<br>
><br>
> However, I would like to find an intermediate solution that avoids full build-up from sources.  My main reasons are (1) test sensitivity to installed ports in the system prefix; (2) save time and effort; and (3) be able to provide compact, uncomplicated reproducers to third parties.<br>
><br>
> If not currently possible, it would be nice to have a new feature to enable local repository testing, with fallback to the system prefix for everything not found in the local repository.<br>
><br>
> What you are asking for is I am afraid really not possible, I suspect. The installation prefix is a fundamental parameter in most port builds. Many directly use this via the ${prefix} variable, which is a single valued path. What you are asking for is for a port use to use one location for some ports and a second one from others. I just don’t see how that could work.<br>
><br>
> I think your only option is really to go with a second installation using a custom prefix.<br>
<br>
The only thing we could potentially do (but sadly I don't see it<br>
coming any time soon unless we get a devoted developer with sufficient<br>
time and skillset willing to work on this) is to support<br>
"relocatability" of packages to avoid building everything from source.<br>
It should be possible to a certain extent (at least our competitors<br>
did it).<br>
<br>
However installing some packages in one prefix and others in another<br>
is going to lead to countless troubles. Binaries have absolute links<br>
to their dependencies. So if you have library A, library B which<br>
depends on A, and binary C which depends on B, you install all three<br>
to /opt/local and then decide to test B in local installation using A<br>
from global prefix, this will generate a mess and will stop working as<br>
soon as A in global prefix is updated. Moreover you also need to<br>
install C to local prefix, else the test won't be "complete". I could<br>
keep on talking about problems, but long story short: not an option.<br>
<br>
Mojca<br></blockquote><div><br></div><div>Chris and Mojca,</div><div><br></div>Thank you for carefully considering this request.  I understand the problems that you described.  I can get by without this feature.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Here is a similar question that might help my current debugging scenario.  This is hypothetical because the source of my current issue was just fixed upstream, so I do not really need to debug this one any further.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Is there an easy way to get macports to go through the motions of "port install -s" for a single port, using macports infrastructure, and taking port dependencies from /opt/local, but writing only inside a user directory?  This would only be for testing that port's build process, not for actually installing into the real port tree.  My now-hypothetical case is a package that fails parallel build under macports, but never fails when parallel building externally, with only autotools.  I would like to find what the differences are, to help make a simpler reproducer.</div></div></div></div></div></div>