[gentoo-pms] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable

[gentoo-pms] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applicable

[James Le Cuirot]

Unfortunately my conception of ESYSROOT was a little short-sighted. It
was previously defined as SYSROOT + EPREFIX but if SYSROOT does not
equal ROOT then EPREFIX does not make sense in this context. Consider
a more concrete example:

BROOT=/foo
ROOT=/bar
PREFIX=/baz
EROOT=/bar/baz
SYSROOT=/

In this scenario, ESYSROOT should be /foo (matching BROOT), not
/baz. From the build system's perspective, /baz does not even exist.

It was also originally envisaged (but not stated in PMS) that SYSROOT
would only ever need to equal / or ROOT as a distinct SYSROOT would
have no benefit. A check was added to Portage to ensure this held.
Myself, the ChromiumOS team, and others have since been caught out by
this check when trying to bootstrap brand new systems from scratch.
You cannot bootstrap with no headers at all! The check will therefore
be adjusted to merely ensure that SYSROOT is / when ROOT is /.

As a result of this original design, no prefix variable for a distinct
SYSROOT was ever established. We therefore assume a blank prefix in
this context. A distinct SYSROOT is most likely to point to a crossdev
toolchain under /usr/${CHOST} but even if pointed elsewhere, it could
include a prefix and still work effectively.

A single variable to hold the SYSROOT prefix, whether determined by /,
ROOT, or the user, would have been nice but it is too late to
introduce one now. In practise, you are unlikely to need one as the
SYSROOT is almost entirely used as a source of headers and libraries
that are best referenced using ESYSROOT. Otherwise, you could simply
derive the value from ${ESYSROOT#${SYSROOT}}.

Signed-off-by: James Le Cuirot <chewi@gentoo.org>
---
 dependencies.tex    | 12 ++++++------
 ebuild-env-vars.tex |  7 ++++---
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/dependencies.tex b/dependencies.tex
index 44382d1..acfebc1 100644
--- a/dependencies.tex
+++ b/dependencies.tex
@@ -32,13 +32,13 @@
     \label{tab:dep-class-api}
     \begin{tabular}{llll}
       \toprule
-                                & \t{BDEPEND}     & \t{DEPEND}         & \t{RDEPEND}, \t{PDEPEND} \\
+                                & \t{BDEPEND}     & \t{DEPEND}                                                                                                                     & \t{RDEPEND}, \t{PDEPEND} \\
       \midrule
-      Binary compatible with    & \t{CBUILD}      & \t{CHOST}          & \t{CHOST}         \\
-      Base unprefixed path      & \t{/}           & \t{\$\{SYSROOT\}}  & \t{\$\{ROOT\}}    \\
-      Relevant offset-prefix    & \t{\$\{BROOT\}} & \t{\$\{EPREFIX\}}  & \t{\$\{EPREFIX\}} \\
-      Path combined with prefix & \t{\$\{BROOT\}} & \t{\$\{ESYSROOT\}} & \t{\$\{EROOT\}}   \\
-      PM query command option   & \t{-b}          & \t{-d}             & \t{-r}            \\
+      Binary compatible with    & \t{CBUILD}      & \t{CHOST}                                                                                                                      & \t{CHOST}         \\
+      Base unprefixed path      & \t{/}           & \t{\$\{SYSROOT\}}                                                                                                              & \t{\$\{ROOT\}}    \\
+      Relevant offset-prefix    & \t{\$\{BROOT\}} & \t{\$\{BROOT\}}, \t{\$\{EPREFIX\}}, or blank if \t{\$\{SYSROOT\}} equals \t{/}, \t{\$\{ROOT\}}, or something else respectively & \t{\$\{EPREFIX\}} \\
+      Path combined with prefix & \t{\$\{BROOT\}} & \t{\$\{ESYSROOT\}}                                                                                                             & \t{\$\{EROOT\}}   \\
+      PM query command option   & \t{-b}          & \t{-d}                                                                                                                         & \t{-r}            \\
       \bottomrule
     \end{tabular}
 \end{centertable}
diff --git a/ebuild-env-vars.tex b/ebuild-env-vars.tex
index 660d17b..45f0a7b 100644
--- a/ebuild-env-vars.tex
+++ b/ebuild-env-vars.tex
@@ -141,9 +141,10 @@ variable.
 \t{ESYSROOT} &
     Ditto &
     No &
-    Contains the concatenation of the paths in the \t{SYSROOT} and \t{EPREFIX} variables,
-    for convenience. See also the \t{EPREFIX} variable. Only for EAPIs listed
-    in table~\ref{tab:offset-env-vars-table} as supporting \t{ESYSROOT}. \\
+    Contains the concatenation of the \t{SYSROOT} path and applicable prefix value. The prefix value
+    is \t{BROOT}, \t{EPREFIX}, or blank if \t{SYSROOT} is equal to /, \t{ROOT}, or something else
+    respectively. Only for EAPIs listed in table~\ref{tab:offset-env-vars-table} as supporting
+    \t{ESYSROOT}. \\
 \t{BROOT} &
     Ditto &
     No &
-- 
2.21.0

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

On Sat, 2019-06-01 at 23:29 +0100, James Le Cuirot wrote:
> Unfortunately my conception of ESYSROOT was a little short-sighted. It
> was previously defined as SYSROOT + EPREFIX but if SYSROOT does not
> equal ROOT then EPREFIX does not make sense in this context. Consider
> a more concrete example:
> 

Once again, you are missing the point that e.g. pkg-config files will
have EPREFIX hardcoded.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

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

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 7592 bytes --]

On Sun, 02 Jun 2019 08:10:34 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Sat, 2019-06-01 at 23:29 +0100, James Le Cuirot wrote:
> > Unfortunately my conception of ESYSROOT was a little short-sighted. It
> > was previously defined as SYSROOT + EPREFIX but if SYSROOT does not
> > equal ROOT then EPREFIX does not make sense in this context. Consider
> > a more concrete example:
> >   
> 
> Once again, you are missing the point that e.g. pkg-config files will
> have EPREFIX hardcoded.

I had remembered that you objected to this but I had forgotten why. I
said at the time that I believed your concerns were misplaced and that
hasn't changed but I wanted to actually try it out to prove it to
myself as much as you.

If EPREFIX is set in the environment by the user, it only applies to
ROOT. If you're emerging a bunch of packages in a single run with some
going to / and some going to ROOT, Portage will adjust EPREFIX for each
destination and hardcode the correct prefix value into the .pc files
accordingly.

Up till now, we have said that you can set SYSROOT to either match / or
ROOT. The former is typically used for native while the latter is
typically used for cross. Whether you're building against / or ROOT,
the .pc files picked up from each will have the prefix hardcoded for
each. This is exactly what we want!

It was surprisingly hard to find a simple package that worked under
prefix and located a header via pkg-config that otherwise would not be
found without an -I flag. After a long search, the package I eventually
settled on was your very own x11-libs/libtinynotify, which uses
pkg-config to query dbus-1.

My setup is as follows:
BROOT=/home/chewi/prefix
ROOT=/home/chewi/myroot
EPREFIX=/myprefix

Therefore, Portage sets:
EROOT=/home/chewi/myroot/myprefix

I wanted to try this with both SYSROOT=/ and SYSROOT=${ROOT}. Without
my associated changes to Portage, the former actually blows up.

  Calculating dependencies... done!
  Traceback (most recent call last):
    File "/home/chewi/prefix/usr/lib/python-exec/python3.6/emerge", line 53, in <module>
      retval = emerge_main()
    File "/home/chewi/prefix/usr/lib64/python3.6/site-packages/_emerge/main.py", line 1289, in emerge_main
      return run_action(emerge_config)
    File "/home/chewi/prefix/usr/lib64/python3.6/site-packages/_emerge/actions.py", line 3325, in run_action
      retval = action_build(emerge_config, spinner=spinner)
    ...
    File "/home/chewi/prefix/usr/lib64/python3.6/site-packages/_emerge/depgraph.py", line 4722, in _select_atoms_highest_available
      pkgsettings = self._frozen_config.pkgsettings[root]
  KeyError: '/myprefix/'

This error precisely highlights the problem with PMS as it stands now.
If SYSROOT=/ and EPREFIX=/myprefix then SYSROOT + EPREFIX is
also /myprefix, which Portage hasn't been told about because it doesn't
even exist. It only exists under /home/chewi/myroot.

With my changes in place, things are resolved as follows. dbus is
installed in both locations because libtinynotify is only EAPI 6.

[ebuild  N     ] sys-apps/dbus-1.12.14 to /home/chewi/myroot/myprefix/ USE="-X -debug -doc -elogind (-selinux) -static-libs -systemd -test -user-session" 
[ebuild  N     ] sys-apps/dbus-1.12.14  USE="-X -debug -doc -elogind (-selinux) -static-libs -systemd -test -user-session" 
[ebuild  N     ] x11-libs/libtinynotify-0.2.1 to /home/chewi/myroot/myprefix/ USE="-debug -doc -static-libs" 

Updating libtinynotify to EAPI 7 while building with SYSROOT=${ROOT}
changes the output to this.

[ebuild  N     ] sys-apps/dbus-1.12.14 to /home/chewi/myroot/myprefix/ USE="-X -debug -doc -elogind (-selinux) -static-libs -systemd -test -user-session" 
[ebuild  N     ] x11-libs/libtinynotify-0.2.1 to /home/chewi/myroot/myprefix/ USE="-debug -doc -static-libs" 

In all cases, both packages build successfully but pkg-config adds
-I/home/chewi/prefix/usr/include/dbus-1.0 regardless of SYSROOT. This
is because native builds like this have no special SYSROOT handling for
pkg-config. This handling exists in crossdev's cross-pkg-config
for cross builds but even that currently has no prefix support
whatsoever. I therefore have some heavy modifications pending for
cross-pkg-config.

It is debatable whether we should apply SYSROOT handling to pkg-config
all the time. While we do technically allow SYSROOT!=/ for native
builds, this is so problematic in general that we probably shouldn't go
out of our way to support it. We don't need to do anything for the
SYSROOT=/ case because the default behaviour is what we want.

In my example, I'm not cross-compiling so I could force the use of
cross-pkg-config to make it work but to keep things simple, I have
written a short bashrc that does the equivalent. This file is placed
in /home/chewi/myroot/myprefix/etc/portage because we only want it to
apply when building packages for ROOT. We therefore need to set
PORTAGE_CONFIGROOT so that it actually gets used.

  if [[ -n ${SYSROOT%/} ]]; then
      myprefix=${EPREFIX%/}
  else
      myprefix=${PORTAGE_OVERRIDE_EPREFIX%/}
  fi

  unset PKG_CONFIG_PATH
  export PKG_CONFIG_SYSTEM_LIBRARY_PATH="${myprefix}/usr/lib64:${myprefix}/lib64"
  export PKG_CONFIG_SYSROOT_DIR="${SYSROOT}"
  export PKG_CONFIG_LIBDIR="${SYSROOT}${myprefix}/usr/lib64/pkgconfig:${SYSROOT}${myprefix}/usr/share/pkgconfig"

In cross-pkg-config, I check ESYSROOT first and determine the prefix by
chopping off SYSROOT. This allows us to support a distinct SYSROOT and
is necessary because we didn't define a variable for SYSROOT's prefix.

For EAPIs before 7, I fall back to something along the lines of the
above. Using PORTAGE_OVERRIDE_EPREFIX works but it's not ideal so I may
just bake the value into cross-pkg-config when crossdev is installed.

And the result? It works as expected. Regardless of whether
libtinynotify uses EAPI 6 or 7, the build output includes the following:

With SYSROOT=/ :

  libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/home/chewi/prefix/usr/include/dbus-1.0 -I/home/chewi/prefix/usr/lib64/dbus-1.0/include -O2 -pipe -O2 -pipe -c lib/common.c  -fPIC -DPIC -o .libs/libtinynotify_la-common.o

With SYSROOT=${ROOT} :

  libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/home/chewi/myroot/myprefix/usr/include/dbus-1.0 -I/home/chewi/myroot/myprefix/usr/lib64/dbus-1.0/include -O2 -pipe -O2 -pipe -c lib/common.c  -fPIC -DPIC -o .libs/libtinynotify_la-common.o

For completeness, I decided to try the distinct SYSROOT case as well
with SYSROOT=/home/chewi/mysysroot. The short bashrc above does not
support this but the revised cross-pkg-config does. You would typically
need the libc and kernel headers installed to this SYSROOT first but I
haven't defined CC="x86_64-pc-linux-gnu-gcc --sysroot=${ESYSROOT}" like
I normally do under cross-boss. Only pkg-config is being affected here,
which is sufficient for this demonstration. And it works!

  libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/home/chewi/mysysroot/usr/include/dbus-1.0 -I/home/chewi/mysysroot/usr/lib64/dbus-1.0/include -O2 -pipe -O2 -pipe -c lib/common.c  -fPIC -DPIC -o .libs/libtinynotify_la-common.o

Distinct SYSROOTs are not something I expect to be used frequently but
they are initially needed when cross-building a brand new system into
an empty directory, which is exactly what cross-boss does.

I hope this makes sense now.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 291 bytes --]

That's a fundamental change of the variable's definition, so presumably
it should be done in EAPI 8, not retroactively?

Also (though not really relevant at this point yet):

    (./dependencies.tex
   Chapter 8.
   Overfull \hbox (282.82272pt too wide) in paragraph at lines 33--44

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

On Sun, 02 Jun 2019 14:28:03 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:

> That's a fundamental change of the variable's definition, so presumably
> it should be done in EAPI 8, not retroactively?

I would say no because the original definition simply doesn't make
sense and there's no point in perpetuating something that doesn't make
sense.

There has also been very little usage of ESYSROOT so far. Practically
all of it has been my own and all of it still fits with the new
definition.

> Also (though not really relevant at this point yet):
> 
>     (./dependencies.tex
>    Chapter 8.
>    Overfull \hbox (282.82272pt too wide) in paragraph at lines 33--44

Sorry, I didn't want to build TeX Live just for this. I'll do it now so
I can work this out.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 394 bytes --]

>>>>> On Thu, 13 Jun 2019, James Le Cuirot wrote:

>> (./dependencies.tex
>> Chapter 8.
>> Overfull \hbox (282.82272pt too wide) in paragraph at lines 33--44

> Sorry, I didn't want to build TeX Live just for this. I'll do it now
> so I can work this out.

Don't bother. I'd suggest not to duplicate the information in the table,
but simply say "(see text)" in the relevant table cell.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]

On Thu, 13 Jun 2019 12:30 +0100
Ulrich Mueller <ulm@gentoo.org> wrote in #gentoo-dev:

> <ulm> Chewi: tbh, I don't understand your update for ESYSROOT
> <ulm> SYSROOT is related to DEPEND/CHOST type dependencies
> <ulm> so why would you have ESYSROOT="/${BROOT}" if SYSROOT is equal to / ? <ulm> since BROOT is related to BDEPEND/CBUILD

I kind of see what you mean but I've been thinking of SYSROOT as being
more like a mechanism to choose between building against BROOT, EROOT
(previously the only two valid options), or some other unprefixed
location. There is no dedicated variable for SYSROOT's prefix so the
user cannot directly define it and it can therefore only be calculated
from BROOT when SYSROOT=/ or EROOT when SYSROOT=${ROOT}.

> <ulm> but if SYSROOT is blank, then ESYSROOT will be blank too, ignoring EPREFIX altogether? (or at least, that's how I read your patch)

What gave you that impression? The rule is that if the prefix cannot be
calculated because SYSROOT is neither / nor ROOT then we have to assume
no prefix. Where else could we get a prefix from?

You may think that we should just create that missing SYSROOT prefix
variable but consider that the distinct "somewhere else" location is
not intended for general use. In other words, you wouldn't execute
commands from it or chroot into it and therefore there is no value in
allowing it to be prefixed. Typically this location would
be /usr/${CHOST} as set up by crossdev.

I haven't forgotten about the cross-prefix case. In this scenario, both
ROOT=/ and SYSROOT=/ but BROOT and EPREFIX are different. Which prefix
do we choose? We pick EPREFIX because the prefix guys try to use the
target prefix as much as possible. Once SYSROOT has the OS headers and
libc headers, you should be able to build anything.

Does this help?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 2371 bytes --]

>>>>> On Thu, 13 Jun 2019, James Le Cuirot wrote:

> On Thu, 13 Jun 2019 12:30 +0100
> Ulrich Mueller <ulm@gentoo.org> wrote in #gentoo-dev:

>> <ulm> Chewi: tbh, I don't understand your update for ESYSROOT
>> <ulm> SYSROOT is related to DEPEND/CHOST type dependencies
>> <ulm> so why would you have ESYSROOT="/${BROOT}" if SYSROOT is equal to / ?
>> <ulm> since BROOT is related to BDEPEND/CBUILD 

> I kind of see what you mean but I've been thinking of SYSROOT as being
> more like a mechanism to choose between building against BROOT, EROOT
> (previously the only two valid options), or some other unprefixed
> location. There is no dedicated variable for SYSROOT's prefix so the
> user cannot directly define it and it can therefore only be calculated
> from BROOT when SYSROOT=/ or EROOT when SYSROOT=${ROOT}.

>> <ulm> but if SYSROOT is blank, then ESYSROOT will be blank too,
>> ignoring EPREFIX altogether? (or at least, that's how I read your
>> patch)

> What gave you that impression? The rule is that if the prefix cannot be
> calculated because SYSROOT is neither / nor ROOT then we have to assume
> no prefix. Where else could we get a prefix from?

> You may think that we should just create that missing SYSROOT prefix
> variable but consider that the distinct "somewhere else" location is
> not intended for general use. In other words, you wouldn't execute
> commands from it or chroot into it and therefore there is no value in
> allowing it to be prefixed. Typically this location would
> be /usr/${CHOST} as set up by crossdev.

> I haven't forgotten about the cross-prefix case. In this scenario, both
> ROOT=/ and SYSROOT=/ but BROOT and EPREFIX are different. Which prefix
> do we choose? We pick EPREFIX because the prefix guys try to use the
> target prefix as much as possible. Once SYSROOT has the OS headers and
> libc headers, you should be able to build anything.

> Does this help?

I fear that after your answer I'm even more confused than I was before.

EPREFIX will be embedded into any (CHOST) binaries being built, so we
want it to be applied in the same way for both DEPEND and RDEPEND,
right? Why would it be appended to ROOT then, but not to SYSROOT?

Also I still don't understand why BROOT (which points to the CBUILD
system) would be used as a prefix for CHOST things.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 3000 bytes --]

On 13 June 2019 23:17:54 BST, Ulrich Mueller <ulm@gentoo.org> wrote:
>
>EPREFIX will be embedded into any (CHOST) binaries being built, so we
>want it to be applied in the same way for both DEPEND and RDEPEND,
>right? Why would it be appended to ROOT then, but not to SYSROOT?
>
>Also I still don't understand why BROOT (which points to the CBUILD
>system) would be used as a prefix for CHOST things.

What do you think SYSROOT is actually used for? As things stand, I'm
aware of:

* cross-pkg-config uses it to source .pc files within SYSROOT and the
  results are adjusted using ${PKG_CONFIG_SYSROOT_DIR}.
* econf adds --with-sysroot="${ESYSROOT:-/}" when the package is built
  with libtool as that is the only component that uses it.
* A small handful of ebuilds.
* My pending Python eclass changes.

If you want to build against a different SYSROOT than the one the
toolchain defaults to then you also need to add --sysroot=${ESYSROOT}
to CC and friends. cross-boss does this for you. I didn't do this in my
earlier prefix example because I was focusing on pkg-config.

Most of the above relates to locating headers and libraries within
SYSROOT to be built against, usually with -I and -L flags. They may
have been built using a different prefix but so what? The SYSROOT
libraries are not the ones that will be used at runtime; those are
built and installed separately into ROOT to satisfy RDEPEND. There are
admittedly a few headers that hard code prefixed paths but these are
the exception.

Remember that the only case where we're potentially forcing the prefix
to be different is the distinct SYSROOT case where it has to be blank.
That case is primarily just for getting the OS headers and libc in
place. We're not stopping users from using the same prefix for BROOT and
EPREFIX if they want to. Conversely, we're not stopping them from using
different prefixes right now either and that's been true since prefix
was introduced. You've always been able to do this from a system with a
different (or blank) prefix:

ROOT=/myroot EPREFIX=/myprefix emerge foo

Without any additional measures in place, this would build against
the build system's libraries and headers, despite the different prefix.
All we're doing now is formalising it around the ESYSROOT variable.

If you think this is too confusing or prone to breakage then we could
add a restriction that forces SYSROOT's prefix to be EPREFIX but this
would be a largely artificial restriction. We would have to change
crossdev to install to /myprefix/usr/${CHOST}/myprefix rather than
just /myprefix/usr/${CHOST} and I fear that could get messy.

I don't personally use prefix so I don't really have a horse in this
race. We're also talking about fairly edgy edge cases here. I've never
heard of any prefix users using ROOT. I just want to make sure our
package manager is built on solid standards that make sense. I also
want to do right by the prefix guys.

Cheers,
Chewi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

On Fri, 14 Jun 2019 23:23:27 +0100
James Le Cuirot <chewi@gentoo.org> wrote:

> If you think this is too confusing or prone to breakage then we could
> add a restriction that forces SYSROOT's prefix to be EPREFIX but this
> would be a largely artificial restriction. We would have to change
> crossdev to install to /myprefix/usr/${CHOST}/myprefix rather than
> just /myprefix/usr/${CHOST} and I fear that could get messy.

Actually I take the crossdev part back. EPREFIX only needs to match
BROOT when SYSROOT=/ and that wouldn't be the case when cross-compiling.
Too tired to think straight now!

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

>>>>> On Sat, 15 Jun 2019, James Le Cuirot wrote:

> I don't personally use prefix so I don't really have a horse in this
> race. We're also talking about fairly edgy edge cases here. I've never
> heard of any prefix users using ROOT. I just want to make sure our
> package manager is built on solid standards that make sense. I also
> want to do right by the prefix guys.

After reading the discussion in bug 317337 again, I think that the
change should be announced on a wider scope, e.g. the gentoo-dev mailing
list. Just to make sure that everybody (prefix people in particular) is
on the same page. And especially, if we go for a retroactive change.

Also, trying to summarise it in a table:

    SYSROOT    ESYSROOT
    -----------------------------------------
    /          ${BROOT}
    ${ROOT}    ${EROOT} (= ${ROOT}${EPREFIX})
    other      ${SYSROOT}
    -----------------------------------------

Is this correct? What happens if both ROOT and SYSROOT are equal to /?
First or second row?

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]