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
