Gentoo Archives: gentoo-user

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] A portage nuisance
Date: Sat, 28 Oct 2017 20:55:31
Message-Id: 9ebcd8df-d618-5fe4-3858-41ae41862588@gmail.com
In Reply to: Re: [gentoo-user] A portage nuisance by Anthony Youngman
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

Replies

Subject Author
Re: [gentoo-user] A portage nuisance Anthony Youngman <antlists@××××××××××××.uk>