Bug 409865 – EPREFIX definition doesn't match reality

• Product: Gentoo Hosted Projects
• Status: RESOLVED OBSOLETE

[Description Brian Harring (RETIRED) 2012-03-27 13:04:07 UTC]

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.

[Comment 1 Jeremy Olexa (darkside) (RETIRED) 2012-03-27 14:27:27 UTC]

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.

[Comment 2 Ulrich Müller 2012-03-27 15:31:19 UTC]

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?

[Comment 3 Fabian Groffen 2012-03-27 15:38:17 UTC]

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.

[Comment 4 Brian Harring (RETIRED) 2012-03-27 23:31:07 UTC]

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

[Comment 5 Fabian Groffen 2012-04-30 18:44:35 UTC]

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

[Comment 6 Fabian Groffen 2017-11-15 17:32:00 UTC]

I think by now the thing is defined in some acceptable way.  @PMS if you disagree, give a shout.