Bugzilla Bug 172511

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