On Thu, Aug 11, 2011 at 08:54:54AM +0200, Fabio Erculiani wrote: > On Thu, Aug 11, 2011 at 7:36 AM, Ciaran McCreesh > <ciaran.mccre...@googlemail.com> wrote: > > 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.
The behaviour is already defined; PDEPEND will be installed at some point, not guranteed to be immediately, soon after, before, or as the very last step. There is *no* gurantee of ordering for a PDEPEND dep. There's nothing to fix here in PMS; the problem is in ebuilds incorrectly assuming ASAP behaviour. > > (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. With respect, "incorrect interpretation of the spec" is "incorrect interpretation of the spec". It's entirely possible, even in ASAP PDEPEND merging, for the pdepend target to wind up very, very far away from what what actually dep'ed it. There is zero difference between that, and arbitrary placement- the ebuild must be written to either RDEP on it if it needs it for runtime, or to PDEP on it and not require it for initial usage. Basically, you're trying to make PDEPEND into a half assed RDEPEND- a "try and schedule it ASAP, but you still can't rely on it being available"; that's actually _worse_ than the current PDEPEND rules since it gives ebuild authors the notion they can most of the time rely on it being ordered prior. Fix the ebuilds; there isn't anything to fix in the spec here. ~harring
