Test in local repository without privileges

[Dave Allured - NOAA Affiliate]

On Sat, Jan 18, 2020 at 3:20 AM Mojca Miklavec <mojca at macports.org> wrote:

> 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
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20200119/e921d11e/attachment.html>