1 |
On Thu, Aug 11, 2011 at 08:54:54AM +0200, Fabio Erculiani wrote: |
2 |
> On Thu, Aug 11, 2011 at 7:36 AM, Ciaran McCreesh |
3 |
> <ciaran.mccreesh@××××××××××.com> wrote: |
4 |
> > Purely as a quality of implementation issue, scheduling a PDEPEND |
5 |
> > reasonably soon after (or even before) the package requiring it may be |
6 |
> > a good idea, simply because users may get confused if when they try to |
7 |
> > install a bunch of things and one of those things gets installed long |
8 |
> > before related packages. But you can't rely upon that happening. |
9 |
> |
10 |
> But since this can lead to failures, the correct behaviour must get |
11 |
> defined by PMS. Otherwise everybody will go implementing schedulers as |
12 |
> they like most. |
13 |
|
14 |
The behaviour is already defined; PDEPEND will be installed at some |
15 |
point, not guranteed to be immediately, soon after, before, or as the |
16 |
very last step. There is *no* gurantee of ordering for a PDEPEND dep. |
17 |
|
18 |
There's nothing to fix here in PMS; the problem is in ebuilds |
19 |
incorrectly assuming ASAP behaviour. |
20 |
|
21 |
|
22 |
> > (Incidentally, one could also argue that package manglers should always |
23 |
> > try to come up with the most perverse legal ordering possible for any |
24 |
> > situation. That way bugs will be identified much more quickly. Part of |
25 |
> > the problem with Portage is that it has so many tricks and so little |
26 |
> > error checking that broken things quite often appear to work.) |
27 |
> |
28 |
> Bad design is bad design. And there is no excuse. |
29 |
> |
30 |
> My feeling is that since Portage is actually able to figure out the |
31 |
> correct order by just using tricks like the "ASAP", and even though |
32 |
> PMS doesn't say anything about that, the issue is considered minor. |
33 |
> I would rather see PMS clarify the correct behaviour of schedulers |
34 |
> with respect to PDEPEND. |
35 |
|
36 |
With respect, "incorrect interpretation of the spec" is "incorrect |
37 |
interpretation of the spec". |
38 |
|
39 |
It's entirely possible, even in ASAP PDEPEND merging, for the pdepend |
40 |
target to wind up very, very far away from what what actually dep'ed |
41 |
it. There is zero difference between that, and arbitrary placement- |
42 |
the ebuild must be written to either RDEP on it if it needs it for |
43 |
runtime, or to PDEP on it and not require it for initial usage. |
44 |
|
45 |
Basically, you're trying to make PDEPEND into a half assed RDEPEND- a |
46 |
"try and schedule it ASAP, but you still can't rely on it being |
47 |
available"; that's actually _worse_ than the current PDEPEND rules |
48 |
since it gives ebuild authors the notion they can most of the time |
49 |
rely on it being ordered prior. |
50 |
|
51 |
Fix the ebuilds; there isn't anything to fix in the spec here. |
52 |
~harring |