On Thu, Aug 11, 2011 at 7:36 AM, Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > On Wed, 10 Aug 2011 23:14:22 +0200 > Fabio Erculiani <lx...@gentoo.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.
Yes, they're legal and common but they can likely generate build failures. > >> 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. > > 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. Given your definition of PDEPEND, jdom stuff should get fixed. No matter what Portage/Paludis quirks do. > > 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. But since this can lead to failures, the correct behaviour must get defined by PMS. Otherwise everybody will go implementing schedulers as they like most. > > (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.) Bad design is bad design. And there is no excuse. My feeling is that since Portage is actually able to figure out the correct order by just using tricks like the "ASAP", and even though PMS doesn't say anything about that, the issue is considered minor. I would rather see PMS clarify the correct behaviour of schedulers with respect to PDEPEND. > > -- > Ciaran McCreesh > -- Fabio Erculiani
