Re: [gentoo-dev] [PMS] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable

[James Le Cuirot]

On Wed, 31 Jul 2019 15:51:58 +0200
Alexis Ballier <aballier@g.o> wrote:

> On Tue, 30 Jul 2019 23:26:27 +0100
> James Le Cuirot <chewi@g.o> wrote:
>
> > > Admittedly without a full understanding of the problem, but this
> > > looks wrong to me: SYSROOT, EPREFIX and BROOT are only relevant in
> > > build phases (src_*); (EPREFIX is a little special here but mostly
> > > for convenience). ROOT is only relevant in pkg_* phases. I don't
> > > see how this can work. Say I build a binpkg with ROOT=/ then use
> > > that binpkg with ROOT=/somewhere, you can't go back and change
> > > SYSROOT.
> >
> > ROOT is used to determine ESYSROOT, not the other way around. As you
> > say, (E)SYSROOT is only relevant in src phases so it doesn't matter if
> > ROOT has changed when installing a binpkg.
>
> I am missing something here: You are making ESYSROOT depend on the
> value of ROOT, so how can it not matter ?

What I am trying to say (somewhat unsuccessfully!) is that the value of
(E)SYSROOT only changes how the package is built, not what the
resulting package looks like. It's where all the headers and libraries
are sourced from at build time, which is irrelevant at runtime.

So why does ROOT affect it? Normally you install the packages for
BDEPEND, DEPEND, and RDEPEND to the same location. If BDEPEND and
RDEPEND are installed to different locations (ROOT!=/) then DEPEND will
almost always be installed to one of the other two. If either of those
two locations is prefixed then we need the prefix for DEPEND's location
to match, otherwise it wouldn't actually be the same location. Using
ROOT allows us to figure this out automatically in a way that covers
all sensible use cases and avoids accidentally falling into an
unsupported case.

I hope that's clearer.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer