1 |
On Thu, Aug 11, 2011 at 7:36 AM, Ciaran McCreesh |
2 |
<ciaran.mccreesh@××××××××××.com> wrote: |
3 |
> On Wed, 10 Aug 2011 23:14:22 +0200 |
4 |
> Fabio Erculiani <lxnay@g.o> wrote: |
5 |
>> I've intermittently spent my last two days trying to figure out a |
6 |
>> weird bug on Entropy dependency resolution algorithm (which is |
7 |
>> actually just a simple topological sorting out of a digraph) |
8 |
> |
9 |
> You can't use a naive topological sort to do dependency resolution. |
10 |
> RDEPEND-RDEPEND cycles are legal and common. |
11 |
|
12 |
Yes, they're legal and common but they can likely generate build failures. |
13 |
|
14 |
|
15 |
> |
16 |
>> Entropy always tried to strictly follow PMS (bugs apart). Given the |
17 |
>> same document, about PDEPEND it says something like this: there is no |
18 |
>> guarantee that a PDEPEND gets installed at a certain, specified point |
19 |
>> during the schedule, if not specifically listed as RDEPEND by some |
20 |
>> package. |
21 |
>> The problem here is that Portage enforces the same rule by trying to |
22 |
>> schedule the PDEPEND "as soon as possible", which leads ebuild writers |
23 |
>> to think to have gotten the deps order right. |
24 |
>> In simple words, it doesn't seem that Portage itself follows PMS or |
25 |
>> PMS is detailed enough. |
26 |
> |
27 |
> Portage *tries*. There's no guarantee that it will succeed. If you need |
28 |
> a particular ordering, you can't use PDEPEND. If something's there only |
29 |
> because of a PDEPEND, there are absolutely no guarantees whatsoever as |
30 |
> to when it will get resolved; PDEPEND imposes absolutely no reliable |
31 |
> conditions upon ordering. Any ebuild assuming otherwise should be fixed. |
32 |
|
33 |
Given your definition of PDEPEND, jdom stuff should get fixed. No |
34 |
matter what Portage/Paludis quirks do. |
35 |
|
36 |
> |
37 |
> Purely as a quality of implementation issue, scheduling a PDEPEND |
38 |
> reasonably soon after (or even before) the package requiring it may be |
39 |
> a good idea, simply because users may get confused if when they try to |
40 |
> install a bunch of things and one of those things gets installed long |
41 |
> before related packages. But you can't rely upon that happening. |
42 |
|
43 |
But since this can lead to failures, the correct behaviour must get |
44 |
defined by PMS. Otherwise everybody will go implementing schedulers as |
45 |
they like most. |
46 |
|
47 |
> |
48 |
> (Incidentally, one could also argue that package manglers should always |
49 |
> try to come up with the most perverse legal ordering possible for any |
50 |
> situation. That way bugs will be identified much more quickly. Part of |
51 |
> the problem with Portage is that it has so many tricks and so little |
52 |
> error checking that broken things quite often appear to work.) |
53 |
|
54 |
Bad design is bad design. And there is no excuse. |
55 |
My feeling is that since Portage is actually able to figure out the |
56 |
correct order by just using tricks like the "ASAP", and even though |
57 |
PMS doesn't say anything about that, the issue is considered minor. |
58 |
I would rather see PMS clarify the correct behaviour of schedulers |
59 |
with respect to PDEPEND. |
60 |
|
61 |
> |
62 |
> -- |
63 |
> Ciaran McCreesh |
64 |
> |
65 |
|
66 |
|
67 |
|
68 |
-- |
69 |
Fabio Erculiani |