Test in local repository without privileges

[Mojca Miklavec]

On Fri, 17 Jan 2020 at 23:44, Christopher Jones
<jonesc at hep.phy.cam.ac.uk> wrote:
> On 17 Jan 2020, at 10:36 pm, Dave Allured - NOAA Affiliate via macports-users <macports-users at 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