if PDEPEND is simply a suggestion that the packages listed should be merged after, then what's the point ? portage currently requires PDEPEND-ed packages to be merged post (i believe), and the description reads: PDEPEND This should contain a list of all packages that will have to be installed after the program has been merged.
Portage doesn't require it. Consider the following slightly oversimplified case: * vim PDEPENDs upon gentoo-syntax * gvim PDEPENDs upon gentoo-syntax * gentoo-syntax RDEPENDs upon || ( vim gvim ) * user does install vim gvim It's perfectly sensible for the resolver to do the order as vim gentoo-syntax gvim. Or, more simply, what if a PDEPEND is already installed? Saying that PDEPEND has to come after doesn't make sense. PDEPENDed packages have to have a complete dep specification anyway; there's no gain to be had from forcing a particular ordering on top of this.
(In reply to comment #0) > portage currently requires PDEPEND-ed packages to be merged post (i believe), It makes a best effort to, but it's not a hard requirement since there would be no benefit and it would unnecessarily limit the possibilities when planning the installation order.
if the current behavior is murky and every one is OK with that, then i'll fix up our docs ... we should earmark this thing for removal come EAPI-1 then since it's clearly useless as you cannot depend on it doing anything specific
Well, it's useful in that RDEPEND is fairly strict in terms of where dependencies can come in, whereas PDEPEND is sufficiently vague not to trigger cycles.
(In reply to comment #3) > > we should earmark this thing for removal come EAPI-1 then since it's clearly > useless as you cannot depend on it doing anything specific > Well would first need to have an alternative.
(In reply to comment #3) > we should earmark this thing for removal come EAPI-1 then since it's clearly > useless as you cannot depend on it doing anything specific It's useful if you want to pull in a package without forcing an order constraint. Order constraints should not be forced unless they are really necessary because they take away freedom from the resolver and may prevent it from solving the problem as efficiently as possible (or worse, result in an unbreakable cycle).
