List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Wed, 10 Aug 2011 23:14:22 +0200
Fabio Erculiani <firstname.lastname@example.org> wrote:
> 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)
You can't use a naive topological sort to do dependency resolution.
RDEPEND-RDEPEND cycles are legal and common.
> 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
> 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.
Portage *tries*. There's no guarantee that it will succeed. If you need
a particular ordering, you can't use PDEPEND. If something's there only
because of a PDEPEND, there are absolutely no guarantees whatsoever as
to when it will get resolved; PDEPEND imposes absolutely no reliable
conditions upon ordering. Any ebuild assuming otherwise should be fixed.
Purely as a quality of implementation issue, scheduling a PDEPEND
reasonably soon after (or even before) the package requiring it may be
a good idea, simply because users may get confused if when they try to
install a bunch of things and one of those things gets installed long
before related packages. But you can't rely upon that happening.
(Incidentally, one could also argue that package manglers should always
try to come up with the most perverse legal ordering possible for any
situation. That way bugs will be identified much more quickly. Part of
the problem with Portage is that it has so many tricks and so little
error checking that broken things quite often appear to work.)