1 |
On 26/09/2015 11:47, lee wrote: |
2 |
> Rich Freeman <rich0@g.o> writes: |
3 |
> |
4 |
>> On Sat, Sep 19, 2015 at 3:57 PM, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
5 |
>>> On 19/09/2015 21:36, lee wrote: |
6 |
>>>> |
7 |
>>>> dev-libs/boost:0 |
8 |
>>>> |
9 |
>>>> (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge) pulled in by |
10 |
>>>> (no parents that aren't satisfied by other packages in this slot) |
11 |
>>>> |
12 |
>>>> (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge) pulled in by |
13 |
>>>> dev-libs/boost:0/1.55.0= required by (dev-libs/librevenge-0.0.2:0/0::gentoo, installed) |
14 |
>>>> ^^^^^^^^^^ |
15 |
>>>> (and 2 more with the same problem) |
16 |
>>> |
17 |
>>> I'm not sure why you are getting this one. Portage is only pulling in |
18 |
>>> boost-1.56.0-r1 because it's the latest stable version, but librevenge |
19 |
>>> requires something earlier. Portage should therefore shut up and install |
20 |
>>> the only real solution - keep boost at 1.55.0 |
21 |
>>> |
22 |
>> |
23 |
>> librevenge doesn't require an earlier version. This is either a |
24 |
>> result of insufficient backtracking, or it might have to do with how |
25 |
>> portage stores runtime dependencies for installed packages. |
26 |
>> |
27 |
>> Try adding --backtrack=50 to your command line and try again. If |
28 |
>> nothing else it might simplify the output. It will take longer to |
29 |
>> run. |
30 |
> |
31 |
> It gives the same results (after syncing again), plus a message that |
32 |
> wasn't there before: |
33 |
> |
34 |
> |
35 |
> ,---- |
36 |
> | x11-drivers/nvidia-drivers:0 |
37 |
> | |
38 |
> | (x11-drivers/nvidia-drivers-355.11:0/0::gentoo, ebuild scheduled for merge) pulled in by |
39 |
> | (no parents that aren't satisfied by other packages in this slot) |
40 |
> | |
41 |
> | (x11-drivers/nvidia-drivers-340.93:0/0::gentoo, ebuild scheduled for merge) pulled in by |
42 |
> | ~x11-drivers/nvidia-drivers-340.93 required by (media-video/nvidia-settings-340.58:0/0::gentoo, ebuild scheduled for merge) |
43 |
> | ^ ^^^^^^ |
44 |
> `---- |
45 |
> |
46 |
> |
47 |
> This looks kinda weird because I expect those drivers to be updated as |
48 |
> well, and if they aren't, I will have to remove nvidia-settings. |
49 |
> |
50 |
> Let's try backtrack 500 ... same result, and doesn't take longer. |
51 |
|
52 |
That doesn't look like a block. It looks like an info message that |
53 |
portage is "helpfully" displaying (but really belongs only in -v output. |
54 |
Maybe even the non-existent -vvv...) |
55 |
|
56 |
Portage is telling you *why* it is not updating to latest stable |
57 |
nvidia-drivers even though a higher version is in the tree. It's because |
58 |
nvidia-settings is out of step with nvidia-drivers. Look at output of |
59 |
"eix nvidia": |
60 |
|
61 |
nvidia-drivers-355.11 is stable |
62 |
nvidia-settings-355.11 is unstable. |
63 |
|
64 |
The driver package will update to 355.11 when the settings package goes |
65 |
stable. |
66 |
|
67 |
A related question is "do you really need the latest nvidia drivers, or |
68 |
is 340.93 still good enough? It was good enough for the entire time you |
69 |
had it installed." |
70 |
|
71 |
> |
72 |
>> If it is the rdepend issue then you can probably emerge -1 librevenge |
73 |
>> and whatever else is depending on the old version to fix it. |
74 |
>> |
75 |
>> Also, emerge running --changed-deps=y from time to time may make those |
76 |
>> kinds of problems less likely. The first time you do it prepare to |
77 |
>> see a LOT of stuff get rebuilt - any of those packages could cause |
78 |
>> issues in the future but most probably will not. |
79 |
> |
80 |
> Good to know, I'll keep that in mind. I tried it and it's not too much |
81 |
> to rebuild, only a bit surprising: |
82 |
> |
83 |
> |
84 |
> ,---- |
85 |
> | [ebuild U ] sys-devel/automake-wrapper-10 [9] |
86 |
> | [ebuild R ] app-benchmarks/i7z-0.27.2 |
87 |
> | [ebuild R ] net-misc/netkit-telnetd-0.17-r10 |
88 |
> | [ebuild R ] virtual/editor-0 |
89 |
> | [ebuild U ] sys-devel/gcc-4.8.5 [4.8.4] USE="-debug%" |
90 |
> | [ebuild R ] net-dialup/ppp-2.4.7 |
91 |
> | [ebuild U ] sys-apps/openrc-0.17 [0.13.11] USE="-audit%" |
92 |
> | [ebuild R ] x11-terms/xterm-314 |
93 |
> | [ebuild U ] net-firewall/shorewall-4.6.10.1 [4.6.6.2] |
94 |
> | [ebuild NS ] sys-devel/automake-1.15 [1.11.6-r1, 1.13.4] |
95 |
> | [ebuild U ] media-libs/alsa-lib-1.0.29 [1.0.28] |
96 |
> | [ebuild U ] media-sound/alsa-utils-1.0.29 [1.0.28] |
97 |
> | [ebuild U ] sys-apps/portage-2.2.20.1 [2.2.18] PYTHON_TARGETS="python3_4* -python3_3*" |
98 |
> | [ebuild R ] app-portage/gentoolkit-0.3.0.9-r2 PYTHON_TARGETS="python3_4* -python3_3*" |
99 |
> | [ebuild U ] dev-python/ssl-fetch-0.3 [0.2] PYTHON_TARGETS="python3_4* -python3_3*" |
100 |
> | [ebuild U ] app-portage/mirrorselect-2.2.2-r2 [2.2.2] PYTHON_TARGETS="python3_4* -python3_3*" |
101 |
> | [ebuild U ] media-gfx/gimp-2.8.14-r1 [2.8.14] USE="{-test%}" |
102 |
> | [ebuild U ] media-video/mplayer-1.2_pre20150214-r1 [1.2_pre20130729] |
103 |
> | [ebuild R ~] media-video/openshot-1.4.3 USE="-libav%" |
104 |
> | [ebuild U ] app-editors/emacs-24.5 [24.4-r4] |
105 |
> `---- |
106 |
> |
107 |
> |
108 |
> Should I do that before updating or after? I guess I'm on the save side |
109 |
> doing it before, so I'll do that. |
110 |
|
111 |
Before, or just include the option in your emerge command. Portage will |
112 |
sort out the order to build them in. |
113 |
|
114 |
Remember something about portage - the only source of info it has about |
115 |
packages is what is in ebuilds. So if say a package from upstream now |
116 |
needs a different version of automake to build correctly, and the dev |
117 |
forgot to add that[1], portage can't take account of it and can't help. |
118 |
|
119 |
Portage also has many useful shortcuts, things like "you don't need to |
120 |
rebuild that package just yet as nothing in the current list needs it |
121 |
yet" so there are options to leave those packages out. But if "nothing |
122 |
needs it yet" is not true because it's missing from ebuilds, you run |
123 |
into a mess. |
124 |
|
125 |
And the really important thing is, portage cannot help resolve this. |
126 |
It's dumb software and has no clue why that build is failing. |
127 |
|
128 |
> |
129 |
>>> You fail to understand how gentoo works. At no time did Gentoo ever |
130 |
>>> guarantee that updates would work like binary distros and the process |
131 |
>>> would be trouble free. Quite the opposite - Gentoo is upfront in telling |
132 |
>>> you that there will always be update issues and you are the person to |
133 |
>>> solve them. |
134 |
>>> |
135 |
>> |
136 |
>> While Gentoo doesn't do as much handholding as many distros, the |
137 |
>> portage output above should not be viewed as something we are proud |
138 |
>> of. |
139 |
> |
140 |
> At least I'm learning here :) |
141 |
|
142 |
Good for you. Learning is always hard. |
143 |
|
144 |
Success has a small learning potential; failure has huge learning |
145 |
potential. And with computing the most valuable lesson is often what not |
146 |
to do. |
147 |
|
148 |
> |
149 |
>> --backtrack fixes a lot of issues, and there aren't a lot of simple |
150 |
>> solutions for that without slowing down emerge. |
151 |
>> |
152 |
>> On the other hand, a lot of the runtime dependency issues could be |
153 |
>> fixed. There is a discussion on -dev right now about getting rid of |
154 |
>> dynamic runtime deps, which would probably help cut down on some of |
155 |
>> the more bizarre behavior. |
156 |
> |
157 |
> Making the output "nicer" --- i. e. more informative --- might go a long |
158 |
> way towards more handholding without slowing things down. If emerge |
159 |
> would tell me "you can ignore this (and look for a solution later if you |
160 |
> like)" and "you need to fix this before you can proceed", I could be |
161 |
> straightforward by updating and looking into fixing things that bother |
162 |
> me eventually. The system would still work fine, or better than before, |
163 |
> after the upgrade, which is the most important issue to begin with. |
164 |
|
165 |
There's a huge problem with that. |
166 |
|
167 |
Seems to me you are thinking like a human (because you are one) and not |
168 |
seeing portage's limits. Portage has no idea what would solve the issue |
169 |
so can't give any recommendations worth a damn. The best it can do is |
170 |
print some hardcoded logic that looks like it might apply. |
171 |
|
172 |
For instance, say you have two packages A and B, and both have USE flag |
173 |
Z. On your system you have A build with Z and B built without Z. After a |
174 |
sync, the latest ebuild for A says that is Z is enabled, then it |
175 |
requires Z also be enabled in B. |
176 |
|
177 |
Portage is not going to just change your USE preferences so it tells you |
178 |
"dude, you need to disable Z for A, or enable it for B. I can't continue |
179 |
till you fix that". Portage can tell you this because the data fits a |
180 |
standard pattern. |
181 |
|
182 |
Ah, but those things are rare. The real world we live in is much more |
183 |
complicated than the exact thing in your PC's RAM - problems are more |
184 |
like cyclic deps that conflict, and portage does not know what you want. |
185 |
|
186 |
Instead it just dumps a crap load of related output and tells you to |
187 |
figure it out, because it can't. |
188 |
|
189 |
Binary distros get around this problem by removing your choice, so the |
190 |
problem never happens there. |
191 |
|
192 |
|
193 |
> |
194 |
> The software would be updated to the best achievable point then. |
195 |
|
196 |
Err, that's exactly what portage already does. In the absence of errors, |
197 |
it updates what it can. Some errors are considered serious enough, with |
198 |
enough possible side-effects, that portage will not continue with a full |
199 |
update till you fix them. You can often get around this by emerging |
200 |
individual packages instead of everything using world |
201 |
|
202 |
> That's |
203 |
> like getting it 95%+ perfect with 0% effort from the user, and that's |
204 |
> pretty darn good. The last 5% usually take 200% of the effort. In this |
205 |
> case, it's impossible to get past 96.5% because the remaining 3.5% |
206 |
> inevitably must be decided by the user. And if the users didn't have |
207 |
> their choices and their powers of making decisions, they'd become very |
208 |
> unhappy with Gentoo. |
209 |
|
210 |
|
211 |
Again, that's exactly what portage does. Perhaps you don't see it yet |
212 |
because portage doesn't pretty-print it's output much. |
213 |
|
214 |
It's been said many times in this thread - the output could be more |
215 |
useful. What usually goes unsaid is that doing that is insanely, |
216 |
amazingly, frickingly HARD. The devs are improving portage all the time, |
217 |
and I'm confident they will improve output when they know how to. Right |
218 |
now, they probably don't, it's still a question without an answer. |
219 |
|
220 |
If you know how to improve it, the devs will happily accept high-quality |
221 |
patches. |
222 |
|
223 |
|
224 |
[1] This is a very easy mistake to make. The dev can easily already have |
225 |
the new version of automake so stuff just works for him. |
226 |
|
227 |
-- |
228 |
Alan McKinnon |
229 |
alan.mckinnon@×××××.com |