1 |
On 28/10/2017 22:39, Anthony Youngman wrote: |
2 |
> On 28/10/17 20:54, Alan McKinnon wrote: |
3 |
>> Portage cannot do that, it is backed by silicon and has no concept of |
4 |
>> meaning. So it has only one real choice - it can do it all or it does |
5 |
>> not try. |
6 |
>> |
7 |
>> I'm not surprised Zac never tried implementing partial graph resolution |
8 |
>> for the very simple reason that if you try do it, you have no idea what |
9 |
>> is going to be built. That is the opposite of what portage must deliver. |
10 |
> |
11 |
> Why is it the opposite of what portage *must* deliver? All I'm asking is |
12 |
> that portage build *what it can*. In other words, I know EXACTLY what it |
13 |
> is going to deliver - its best effort! |
14 |
|
15 |
Dude, calm down. Showing me that you are upset isn't going to change |
16 |
jack shit. |
17 |
|
18 |
> |
19 |
> And why does portage *have* to choose between all or nothing? All I'm |
20 |
> asking is that if it can't resolve everything, I want it to resolve |
21 |
> everything it can. Silicon is perfectly capable of making that decision. |
22 |
|
23 |
because "everything it can" is not necessarily the same thing as |
24 |
"everything it should" or "everything it was asked to do" |
25 |
|
26 |
Portage has no idea at all why the depgraph failed to resolve fully at |
27 |
the start. It knows about blockers that are in it's own ebuilds and can |
28 |
deal with those; the way ebuilds are spec'ed a package manager can |
29 |
cleave off an entire branch of the tree and build the remainder fully |
30 |
confident that each part of what it then does build is identical to the |
31 |
same parts if the blockers never hit the rest. It's deterministic and so |
32 |
portage can continue. |
33 |
|
34 |
For everything else, the input is not completely known therefore the |
35 |
output cannot be completely known either and portage does the correct |
36 |
thing and not try guess. This is a good thing. |
37 |
|
38 |
> |
39 |
> If I say "emerge -u world" I have no idea what it's going to build, if I |
40 |
> say "emerge -u best-efforts", I have no idea what it's going to build, |
41 |
> where's the difference? |
42 |
> |
43 |
> What I do know, is if I repeat "emerge -u best-efforts" several times, I |
44 |
> will end up (in all likelihood) with the same result as "emerge -u world". |
45 |
|
46 |
No, you will not. In this case, what portage will give is not the sum of |
47 |
it's individual parts as there is a real risk that some attributes of |
48 |
the various parts are WRONG. Therefore the output can be WRONG. It |
49 |
really is that simple. |
50 |
|
51 |
You even said it yourself when you used the phrase "in all likelihood". |
52 |
What about when it isn't? This is a package manager and package managers |
53 |
have one singular objective that the code must always deliver: the |
54 |
output must be entirely deterministic. Anything other than that and you |
55 |
do not have a package manager anymore, now you have software that puts |
56 |
stuff on a disk. |
57 |
|
58 |
Portage is doing the right thing when it detects invalid input that it |
59 |
cannot reliably - it stops. |
60 |
|
61 |
But feel free to disagree. If you can do this, the proof is in code and |
62 |
patches. Got any? |
63 |
|
64 |
|
65 |
-- |
66 |
Alan McKinnon |
67 |
alan.mckinnon@×××××.com |