[gentoo-dev] The fun of being a PDEPEND

[Fabio Erculiani]

I've intermittently spent my last two days trying to figure out a
weird bug on Entropy dependency resolution algorithm (which is
actually just a simple topological sorting out of a digraph) due to an
user reporting me a problem occurring during app-office/libreoffice
pkg_setup phase. The problem is actually two problems, but anyways, to
make it short (since it's not the topic here), bug #206024 is also a
reason why I've been hit by all this mess.

Entropy always tried to strictly follow PMS (bugs apart). Given the
same document, about PDEPEND it says something like this: there is no
guarantee that a PDEPEND gets installed at a certain, specified point
during the schedule, if not specifically listed as RDEPEND by some
package.
The problem here is that Portage enforces the same rule by trying to
schedule the PDEPEND "as soon as possible", which leads ebuild writers
to think to have gotten the deps order right.
In simple words, it doesn't seem that Portage itself follows PMS or
PMS is detailed enough.

Try to ask your fellow developers this question: what is a PDEPEND?
And you will get several different answers. The fact is, at least
among us, it's still unclear what a PDEPEND is and how it behaves,
also given the fact that other PMs strictly following the
specifications end up generating wrong merge schedules.
There are two main interpretations of what a PDEPEND is:
1. a way to fix circular dependecies (actually, it's wrong because
there is no guarantee on the scheduling)
2. a way to have some handy packages being pulled in at some point
(audacious plugins?)

Who is this poor little PDEPEND?
I think it's time to take action and fix the gray area around
PDEPENDs, or at least clarify the fact to us developers.

-- 
Fabio Erculiani