User:Kentnl/Thinking In Prefix

I'm just gonna start encoding how I understand the various prefix control structures in the hope somebody finds it useful, and maybe some salient documentation can emerge from it.

EPREFIX
In my understanding,  is a string that is to be considered to be possibly injected into the final binaries, but also used to derive a "final resting place" relative to "the root of your target environment", and is used for various install paths.

In that, if EPREFIX was "/alternative", and the code was compiled with: --prefix="${EPREFIX}/usr"

That a binary shipped with the package would be intended to get stored in "/alternative/usr/bin/myname", and in the final environment of execution, running said binary, that binary could also  and expect to find itself.

This is not a chroot situation, and doing a chroot into 'alternative' would give you a broken chroot, as calling  would get translated by the kernel to , which wouldn't exist.

In a pure chroot situation, it would be  that changes, and this should be invisible during src_compile and friends.

Portage would set, the code would compile (mostly) under the assumption its getting installed to "/", while *actually* getting installed to a path in  , which would then get transplanted to your chroot path "/alternative-chroot". That way, inside the chroot, all the paths are predicted to be sensible.

Subsequently, unless you're doing things outside the various src_* phases, that need to modify paths in the final destination, you probably don't need to even think about  or , as these are paths portage has mostly dealt with for you.

Various builtin functions also assume you want  used, so if a function like   existed,   would implicitly mean

RDEPEND

 * 1) Must be available on the final target at runtime
 * 2) May not be necessarily usable on the build environment (CBUILD) if cross-compilation is occurring.