In EAPI 0, the DEPEND, RDEPEND, and PDEPEND variables do not provide enough granularity to fully model a cross-compiling environment. Portage currently interprets DEPEND as a build platform dependency, while there is no way to explicitly specify a build-time dependency that must be installed into the cross-compiled platform. Perhaps we should add a new BDEPEND variable that represents this type of dependency.
i'm guessing ABI support falls into this realm as well ?
I consider ABI support to be an orthogonal concern. My main intention for this bug is simply to have better support for building packages and installing them to an alternate $ROOT that may or may not be cross-compiled. Portage interprets DEPEND as a build-time dependency that should be installed to ROOT=/ (the build platform). We currently have no way to specify a build-time dependency that should be installed to ROOT=/some/other/root/ (cross-compiled or not), so I've suggested that we use BDEPEND to represent that.
So with this change, what will the meanings of DEPEND, RDEPEND, PDEPEND and BDEPEND be in terms of what gets installed where?
For a package being installed to $ROOT, it's dependencies will be installed as follows:
type location time
DEPEND build platform before
BDEPEND $ROOT before
RDEPEND $ROOT before or approximately the same time
PDEPEND $ROOT after or possibly before
Just a vague thought... Given that there is a high degree of overlay between DEPEND and RDEPEND in many cases, and that RDEPEND=DEPEND will be dropped... Are dependencies best specified as multiple variables? Or would a single DEPEND variable with a way of marking dependency classes on each item be better? Something like the following (syntax purely for demonstration):
with a default of build,run?
*shrug* Possibly worth considering. It'll avoid the need for an explosion of *DEPEND variables and can probably scale to handling ABI type dependencies.
The nice thing about BDEPEND is that it's a relatively simple extension of the existing multi-variable style. I'm not sure how far we should go in EAPI-1 but the single-variable approach is certainly worth considering (at least in the long run).
*** Bug 200057 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 201499 ***
*** Bug 219623 has been marked as a duplicate of this bug. ***