1 |
Alan McKinnon <alan.mckinnon@×××××.com> writes: |
2 |
|
3 |
> On 26/09/2015 11:47, lee wrote: |
4 |
>> Rich Freeman <rich0@g.o> writes: |
5 |
>> |
6 |
>>> On Sat, Sep 19, 2015 at 3:57 PM, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
7 |
|
8 |
> [...] |
9 |
>> It gives the same results (after syncing again), plus a message that |
10 |
>> wasn't there before: |
11 |
>> |
12 |
>> |
13 |
>> ,---- |
14 |
>> | x11-drivers/nvidia-drivers:0 |
15 |
>> | |
16 |
>> | (x11-drivers/nvidia-drivers-355.11:0/0::gentoo, ebuild scheduled for merge) pulled in by |
17 |
>> | (no parents that aren't satisfied by other packages in this slot) |
18 |
>> | |
19 |
>> | (x11-drivers/nvidia-drivers-340.93:0/0::gentoo, ebuild scheduled for merge) pulled in by |
20 |
>> | ~x11-drivers/nvidia-drivers-340.93 required by (media-video/nvidia-settings-340.58:0/0::gentoo, ebuild scheduled for merge) |
21 |
>> | ^ ^^^^^^ |
22 |
>> `---- |
23 |
>> |
24 |
>> |
25 |
>> This looks kinda weird because I expect those drivers to be updated as |
26 |
>> well, and if they aren't, I will have to remove nvidia-settings. |
27 |
>> |
28 |
>> Let's try backtrack 500 ... same result, and doesn't take longer. |
29 |
> |
30 |
> That doesn't look like a block. It looks like an info message that |
31 |
> portage is "helpfully" displaying (but really belongs only in -v output. |
32 |
> Maybe even the non-existent -vvv...) |
33 |
> |
34 |
> Portage is telling you *why* it is not updating to latest stable |
35 |
> nvidia-drivers even though a higher version is in the tree. It's because |
36 |
> nvidia-settings is out of step with nvidia-drivers. Look at output of |
37 |
> "eix nvidia": |
38 |
> |
39 |
> nvidia-drivers-355.11 is stable |
40 |
> nvidia-settings-355.11 is unstable. |
41 |
> |
42 |
> The driver package will update to 355.11 when the settings package goes |
43 |
> stable. |
44 |
> |
45 |
> A related question is "do you really need the latest nvidia drivers, or |
46 |
> is 340.93 still good enough? It was good enough for the entire time you |
47 |
> had it installed." |
48 |
|
49 |
Do I need to update at all? After all, the system has been running fine |
50 |
all the time, except that I wanted the latest version of seamonkey and |
51 |
that I tend to update every three months or so as time permits, and the |
52 |
last update was almost haft a year ago or so. |
53 |
|
54 |
Of course I want the latest nvidia drivers, so I removed |
55 |
nvidia-settings. (I have updated, and it took almost 2 days.) |
56 |
|
57 |
Nvidia-settings is kinda weird anyway, like when you enable sync to |
58 |
vblanc, apparently that is somehow being remembered, and the question is |
59 |
"when is it applied": When you start an X session or when you start |
60 |
nvidia-settings. Same goes for all the other settings you can make with |
61 |
it. |
62 |
|
63 |
And now, with nvidia drivers incompatible with nvidia-settings and |
64 |
nvidia-settings not installed, what settings that have been made with it |
65 |
are applied? |
66 |
|
67 |
>>> If it is the rdepend issue then you can probably emerge -1 librevenge |
68 |
>>> and whatever else is depending on the old version to fix it. |
69 |
>>> |
70 |
>>> Also, emerge running --changed-deps=y from time to time may make those |
71 |
>>> kinds of problems less likely. The first time you do it prepare to |
72 |
>>> see a LOT of stuff get rebuilt - any of those packages could cause |
73 |
>>> issues in the future but most probably will not. |
74 |
>> |
75 |
>> Good to know, I'll keep that in mind. I tried it and it's not too much |
76 |
>> to rebuild, only a bit surprising: |
77 |
> [...] |
78 |
>> |
79 |
>> Should I do that before updating or after? I guess I'm on the save side |
80 |
>> doing it before, so I'll do that. |
81 |
> |
82 |
> Before, or just include the option in your emerge command. Portage will |
83 |
> sort out the order to build them in. |
84 |
|
85 |
Ok --- I did it before and after ... |
86 |
|
87 |
> Remember something about portage - the only source of info it has about |
88 |
> packages is what is in ebuilds. So if say a package from upstream now |
89 |
> needs a different version of automake to build correctly, and the dev |
90 |
> forgot to add that[1], portage can't take account of it and can't help. |
91 |
> |
92 |
> Portage also has many useful shortcuts, things like "you don't need to |
93 |
> rebuild that package just yet as nothing in the current list needs it |
94 |
> yet" so there are options to leave those packages out. But if "nothing |
95 |
> needs it yet" is not true because it's missing from ebuilds, you run |
96 |
> into a mess. |
97 |
> |
98 |
> And the really important thing is, portage cannot help resolve this. |
99 |
> It's dumb software and has no clue why that build is failing. |
100 |
|
101 |
Isn't that the same for all package management software? |
102 |
|
103 |
>>>> You fail to understand how gentoo works. At no time did Gentoo ever |
104 |
>>>> guarantee that updates would work like binary distros and the process |
105 |
>>>> would be trouble free. Quite the opposite - Gentoo is upfront in telling |
106 |
>>>> you that there will always be update issues and you are the person to |
107 |
>>>> solve them. |
108 |
>>>> |
109 |
>>> |
110 |
>>> While Gentoo doesn't do as much handholding as many distros, the |
111 |
>>> portage output above should not be viewed as something we are proud |
112 |
>>> of. |
113 |
>> |
114 |
>> At least I'm learning here :) |
115 |
> |
116 |
> Good for you. Learning is always hard. |
117 |
|
118 |
Some years ago I found out that the learning isn't the problem when I |
119 |
was like "I don't want to do this (because I need to learn it)" and then |
120 |
did and learned it. The problem is bringing oneself to do it. |
121 |
|
122 |
> Success has a small learning potential; failure has huge learning |
123 |
> potential. And with computing the most valuable lesson is often what not |
124 |
> to do. |
125 |
|
126 |
Not really: You end up learning so much about what not to do that you |
127 |
can't do anything anymore because you have learned not to do it. If you |
128 |
don't experiment sufficiently and don't allow yourself to fail, you get |
129 |
stuck and become unable to extend your limits. Success is required for |
130 |
without it, you won't make any progress and give up eventually. A |
131 |
failure can be a success, depending on your approach. |
132 |
|
133 |
>>> --backtrack fixes a lot of issues, and there aren't a lot of simple |
134 |
>>> solutions for that without slowing down emerge. |
135 |
>>> |
136 |
>>> On the other hand, a lot of the runtime dependency issues could be |
137 |
>>> fixed. There is a discussion on -dev right now about getting rid of |
138 |
>>> dynamic runtime deps, which would probably help cut down on some of |
139 |
>>> the more bizarre behavior. |
140 |
>> |
141 |
>> Making the output "nicer" --- i. e. more informative --- might go a long |
142 |
>> way towards more handholding without slowing things down. If emerge |
143 |
>> would tell me "you can ignore this (and look for a solution later if you |
144 |
>> like)" and "you need to fix this before you can proceed", I could be |
145 |
>> straightforward by updating and looking into fixing things that bother |
146 |
>> me eventually. The system would still work fine, or better than before, |
147 |
>> after the upgrade, which is the most important issue to begin with. |
148 |
> |
149 |
> There's a huge problem with that. |
150 |
> |
151 |
> Seems to me you are thinking like a human (because you are one) and not |
152 |
> seeing portage's limits. Portage has no idea what would solve the issue |
153 |
> so can't give any recommendations worth a damn. The best it can do is |
154 |
> print some hardcoded logic that looks like it might apply. |
155 |
|
156 |
According to that, the human is even less able to figure out what might |
157 |
solve the problem than portage is: The human doesn't know anything about |
158 |
the huge number of dependencies involved, and even if they did, it would |
159 |
take them really really long to go through all of them to figure out |
160 |
anything at all. Now if they do it right, the human would come to the |
161 |
same conclusion as portage, provided that portage does it right. |
162 |
|
163 |
> For instance, say you have two packages A and B, and both have USE flag |
164 |
> Z. On your system you have A build with Z and B built without Z. After a |
165 |
> sync, the latest ebuild for A says that is Z is enabled, then it |
166 |
> requires Z also be enabled in B. |
167 |
> |
168 |
> Portage is not going to just change your USE preferences so it tells you |
169 |
> "dude, you need to disable Z for A, or enable it for B. I can't continue |
170 |
> till you fix that". Portage can tell you this because the data fits a |
171 |
> standard pattern. |
172 |
|
173 |
That's the same thing the human would figure out. |
174 |
|
175 |
> Ah, but those things are rare. The real world we live in is much more |
176 |
> complicated than the exact thing in your PC's RAM - problems are more |
177 |
> like cyclic deps that conflict, and portage does not know what you want. |
178 |
> |
179 |
> Instead it just dumps a crap load of related output and tells you to |
180 |
> figure it out, because it can't. |
181 |
> |
182 |
> Binary distros get around this problem by removing your choice, so the |
183 |
> problem never happens there. |
184 |
|
185 |
That wasn't at all my point. I don't expect portage to figure out what |
186 |
a human cannot figure out. I don't expect portage to make a decision a |
187 |
human needs to make. |
188 |
|
189 |
All I'm saying is, make it easier for the human to figure out what |
190 |
portage has figured out by providing the human with better messages. |
191 |
|
192 |
I'm sure portage does "know" which things *must* be "fixed" by a human |
193 |
decision (like the USE flags) and which ones need not be fixed by human |
194 |
decision. So it could just tell the human, as I suggested, either: "you |
195 |
must fix this" or "you my ignore this". |
196 |
|
197 |
From there, the human can figure out what they need to fix and go from |
198 |
there. That's what I did in this case, and guess what, there were no |
199 |
slot conflicts after fixing the USE flags. |
200 |
|
201 |
>> The software would be updated to the best achievable point then. |
202 |
> |
203 |
> Err, that's exactly what portage already does. In the absence of errors, |
204 |
> it updates what it can. Some errors are considered serious enough, with |
205 |
> enough possible side-effects, that portage will not continue with a full |
206 |
> update till you fix them. You can often get around this by emerging |
207 |
> individual packages instead of everything using world |
208 |
|
209 |
Then why should it be such a huge problem to have portage tell us what |
210 |
we need to fix in the first place? Let us humans fix just that and try |
211 |
again and see what happens, breaking down the problem into more |
212 |
manageable steps. That would suit both the human and the computer. |
213 |
|
214 |
>> That's |
215 |
>> like getting it 95%+ perfect with 0% effort from the user, and that's |
216 |
>> pretty darn good. The last 5% usually take 200% of the effort. In this |
217 |
>> case, it's impossible to get past 96.5% because the remaining 3.5% |
218 |
>> inevitably must be decided by the user. And if the users didn't have |
219 |
>> their choices and their powers of making decisions, they'd become very |
220 |
>> unhappy with Gentoo. |
221 |
> |
222 |
> |
223 |
> Again, that's exactly what portage does. Perhaps you don't see it yet |
224 |
> because portage doesn't pretty-print it's output much. |
225 |
|
226 |
It throws lots of errors, making irrelevant ones appear as most |
227 |
important and most important ones appear as minor. It doesn't take |
228 |
pretty-printing to do it the other way round, or to shut up about |
229 |
irrelevant errors until the most important ones are fixed. |
230 |
|
231 |
> It's been said many times in this thread - the output could be more |
232 |
> useful. What usually goes unsaid is that doing that is insanely, |
233 |
> amazingly, frickingly HARD. The devs are improving portage all the time, |
234 |
> and I'm confident they will improve output when they know how to. Right |
235 |
> now, they probably don't, it's still a question without an answer. |
236 |
> |
237 |
> If you know how to improve it, the devs will happily accept high-quality |
238 |
> patches. |
239 |
|
240 |
Ok, why is that so incredibly hard? |
241 |
|
242 |
Somewhere, there must be a 'print' statement where it says "slot |
243 |
conflict". Add to that that those "can probably be ignored before other |
244 |
problems are fixed" (and remove all these exclamation marks while you |
245 |
are at it), and the human would tend to fix the other errors and the |
246 |
slot conflicts might go away automagically just like they did in this |
247 |
case. |
248 |
|
249 |
If that is too hard, I would have to assume that portage doesn't "know" |
250 |
whether there's a slot conflict or not and be amazed as to how it |
251 |
produces any messages about them. |
252 |
|
253 |
|
254 |
> [1] This is a very easy mistake to make. The dev can easily already have |
255 |
> the new version of automake so stuff just works for him. |
256 |
|
257 |
-- |
258 |
Again we must be afraid of speaking of daemons for fear that daemons |
259 |
might swallow us. Finally, this fear has become reasonable. |