On Sat, Jan 18, 2020 at 3:20 AM Mojca Miklavec <mo...@macports.org> wrote:
> On Fri, 17 Jan 2020 at 23:44, Christopher Jones > <jon...@hep.phy.cam.ac.uk> wrote: > > On 17 Jan 2020, at 10:36 pm, Dave Allured - NOAA Affiliate via > macports-users <macports-users@lists.macports.org> wrote: > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > > > I think your only option is really to go with a second installation > using a custom prefix. > > The only thing we could potentially do (but sadly I don't see it > coming any time soon unless we get a devoted developer with sufficient > time and skillset willing to work on this) is to support > "relocatability" of packages to avoid building everything from source. > It should be possible to a certain extent (at least our competitors > did it). > > However installing some packages in one prefix and others in another > is going to lead to countless troubles. Binaries have absolute links > to their dependencies. So if you have library A, library B which > depends on A, and binary C which depends on B, you install all three > to /opt/local and then decide to test B in local installation using A > from global prefix, this will generate a mess and will stop working as > soon as A in global prefix is updated. Moreover you also need to > install C to local prefix, else the test won't be "complete". I could > keep on talking about problems, but long story short: not an option. > > Mojca > Chris and Mojca, Thank you for carefully considering this request. I understand the problems that you described. I can get by without this feature. 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. 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.