1 |
On 28/10/17 21:50, Alan McKinnon wrote: |
2 |
> On 28/10/2017 22:39, Anthony Youngman wrote: |
3 |
>> On 28/10/17 20:54, Alan McKinnon wrote: |
4 |
>>> Portage cannot do that, it is backed by silicon and has no concept of |
5 |
>>> meaning. So it has only one real choice - it can do it all or it does |
6 |
>>> not try. |
7 |
>>> |
8 |
>>> I'm not surprised Zac never tried implementing partial graph resolution |
9 |
>>> for the very simple reason that if you try do it, you have no idea what |
10 |
>>> is going to be built. That is the opposite of what portage must deliver. |
11 |
>> |
12 |
>> Why is it the opposite of what portage *must* deliver? All I'm asking is |
13 |
>> that portage build *what it can*. In other words, I know EXACTLY what it |
14 |
>> is going to deliver - its best effort! |
15 |
> |
16 |
> Dude, calm down. Showing me that you are upset isn't going to change |
17 |
> jack shit. |
18 |
> |
19 |
Sorry - I'm not upset. I just think you are missing what I'm asking for. |
20 |
>> |
21 |
>> And why does portage *have* to choose between all or nothing? All I'm |
22 |
>> asking is that if it can't resolve everything, I want it to resolve |
23 |
>> everything it can. Silicon is perfectly capable of making that decision. |
24 |
> |
25 |
> because "everything it can" is not necessarily the same thing as |
26 |
> "everything it should" or "everything it was asked to do" |
27 |
> |
28 |
> Portage has no idea at all why the depgraph failed to resolve fully at |
29 |
> the start. It knows about blockers that are in it's own ebuilds and can |
30 |
> deal with those; the way ebuilds are spec'ed a package manager can |
31 |
> cleave off an entire branch of the tree and build the remainder fully |
32 |
> confident that each part of what it then does build is identical to the |
33 |
> same parts if the blockers never hit the rest. It's deterministic and so |
34 |
> portage can continue. |
35 |
> |
36 |
And if we are understanding each other correctly, THIS is the point at |
37 |
which I would expect portage to give up and terminate. Except you seem |
38 |
to be saying it doesn't terminate here ... |
39 |
|
40 |
> For everything else, the input is not completely known therefore the |
41 |
> output cannot be completely known either and portage does the correct |
42 |
> thing and not try guess. This is a good thing. |
43 |
> |
44 |
You think it terminates here ... |
45 |
>> |
46 |
>> If I say "emerge -u world" I have no idea what it's going to build, if I |
47 |
>> say "emerge -u best-efforts", I have no idea what it's going to build, |
48 |
>> where's the difference? |
49 |
>> |
50 |
>> What I do know, is if I repeat "emerge -u best-efforts" several times, I |
51 |
>> will end up (in all likelihood) with the same result as "emerge -u world". |
52 |
> |
53 |
> No, you will not. In this case, what portage will give is not the sum of |
54 |
> it's individual parts as there is a real risk that some attributes of |
55 |
> the various parts are WRONG. Therefore the output can be WRONG. It |
56 |
> really is that simple. |
57 |
|
58 |
When I run portage, it displays a list of what it is going to emerge. As |
59 |
I understand it, as each package is displayed of what it is going to |
60 |
emerge, that means it has successfully resolved the dependency graph. It |
61 |
also displays packages that are blocked. And then sometimes it just goes |
62 |
into a tizzy and says "too many blocks - giving up". |
63 |
|
64 |
All I'm asking is that as it progresses, it makes a list of those |
65 |
packages it can resolve the dependencies for. If it then gives up with |
66 |
the current list it's processing, eg "world", it then goes back to the |
67 |
list it thinks it can process, and has another go with them. |
68 |
|
69 |
Because that's exactly what I do, take the first few packages off the |
70 |
list that look fine, and emerge them. I then re-run the original emerge, |
71 |
rinse and repeat, but it takes absolutely ages, and worse I have to |
72 |
babysit the emerge because I'm *expecting* it to hit a problem. |
73 |
> |
74 |
> You even said it yourself when you used the phrase "in all likelihood". |
75 |
> What about when it isn't? This is a package manager and package managers |
76 |
> have one singular objective that the code must always deliver: the |
77 |
> output must be entirely deterministic. Anything other than that and you |
78 |
> do not have a package manager anymore, now you have software that puts |
79 |
> stuff on a disk. |
80 |
> |
81 |
> Portage is doing the right thing when it detects invalid input that it |
82 |
> cannot reliably - it stops. |
83 |
|
84 |
Why can't it just discard the invalid input, and try again with input |
85 |
that appears valid? |
86 |
|
87 |
Note I didn't say *continue* - I said "try again". From the beginning. |
88 |
|
89 |
I'm sorry, but the current behaviour is reminiscent of the way |
90 |
programmers (used to) code huge green-screen input forms - when you get |
91 |
to the bottom and hit "submit" - one error and it throws the whole lot |
92 |
away and makes you start again from scratch! |
93 |
> |
94 |
> But feel free to disagree. If you can do this, the proof is in code and |
95 |
> patches. Got any? |
96 |
> |
97 |
What language? Python? Sorry, at the moment I don't speak Python - maybe |
98 |
I should. |
99 |
|
100 |
And I hate to say it, but demanding code and patches is NOT good form. |
101 |
Yes, far too many people do it, but not everybody is a programmer (I am, |
102 |
but it's C and DataBasic). And do you REALLY want jack-of-all-trades |
103 |
giving you dodgy code? I contribute elsewhere. Fixing emerge is not |
104 |
really my thing, I'm just chucking out an idea I would find very useful |
105 |
(and I expect other people will too). I'm one of those odd people who |
106 |
actually *enjoy* maintenance work, rather than new stuff, and I'm hoping |
107 |
someone like me in the gentoo project will pick up this idea and run |
108 |
with it. I'm busy doing maintenance work elsewhere with what time I have ... |
109 |
|
110 |
To give you a very clear example of what I'm thinking ... |
111 |
|
112 |
emerge -u world |
113 |
A will be emerged with options ... |
114 |
B will be emerged with options ... |
115 |
C will be emerged with options ... |
116 |
D is blocked by E |
117 |
F will be emerged with options ... |
118 |
G is blocked by H |
119 |
Giving up, too many circular dependencies |
120 |
emerge A B C F |
121 |
... |
122 |
... |
123 |
... |
124 |
|
125 |
That is what I do manually, it would be nice if emerge could do it for me. |
126 |
|
127 |
Cheers, |
128 |
Wol |