Quoting: "The normalised offset-prefix path of an offset installation. When EPREFIX is not set in the calling environment, EPREFIX defaults to the built-in offset-prefix that was set during installation of the package manager. When a different EPREFIX value than the built-in value is set in the calling environment, a cross-prefix build is performed where using the existing utilities..." Current ebuild requirements (cmake in particular), requires EPREFIX to be empty in the normal case of root=/ for a normal system level install. Literally, EPREFIX=/ causes it to go boom (code gets cranky since various prefixing results in //usr rather than /usr) The phrasing of PMS implies this is valid/allowed, although the reality as indicated doesn't quite match it. Probably best to tighten the wording.
FYI, some* of our users do set EPREFIX=/ to install the Gentoo userland onto the root of a non-Gentoo OS *Maybe only one person does that and the Prefix team doesn't test it.
The relevant commit is here: <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=f49a53b3a97dbe299f1b71dad5a6bf5b9b6805ba>, but the wording originates from bug 296716. @grobian: Can you comment about this?
originally: When EPREFIX="", you don't have an offset-prefix. EPREFIX does *not* end with a slash, hence the empty EPREFIX for non-Prefix. Current reality is that cross-Prefix merging is broken and "disabled", that is, Portage should not do anything with EPREFIX in calling env these days. Zac implemented something similar, but not quite the same. I personally gave up on it, but mduft and haubi might still need it.
(In reply to comment #3) > originally: > > When EPREFIX="", you don't have an offset-prefix. EPREFIX does *not* end > with a slash, hence the empty EPREFIX for non-Prefix. Grok. My point is the PMS wording, at least to me, implies otherwise (normalized bit); this bug should be sortable just via tweaking that wording, assuming this is behaviour we wish to maintain.
(In reply to comment #4) > (In reply to comment #3) > > originally: > > > > When EPREFIX="", you don't have an offset-prefix. EPREFIX does *not* end > > with a slash, hence the empty EPREFIX for non-Prefix. > Grok. My point is the PMS wording, at least to me, implies otherwise > (normalized bit); this bug should be sortable just via tweaking that > wording, assuming this is behaviour we wish to maintain. If you are looking for something like EPREFIX does not end in a slash. This means that an absent offset-prefix is represented as EPREFIX="", which coincides with the value of the unset variable. then that works for me.
I think by now the thing is defined in some acceptable way. @PMS if you disagree, give a shout.
