1 |
On 20/09/2015 17:28, lee wrote: |
2 |
> Neil Bothwick <neil@××××××××××.uk> writes: |
3 |
> |
4 |
>> On Sat, 19 Sep 2015 21:36:06 +0200, lee wrote: |
5 |
>> |
6 |
>>> emerge -j 8 -a --update --newuse --deep --with-bdeps=y |
7 |
>>> @world |
8 |
>>> |
9 |
>>> * IMPORTANT: 4 news items need reading for repository 'gentoo'. |
10 |
>>> * Use eselect news read to view new items. |
11 |
>>> |
12 |
>>> |
13 |
>>> These are the packages that would be merged, in order: |
14 |
>>> |
15 |
>>> Calculating dependencies... done! |
16 |
>>> |
17 |
>>> !!! Multiple package instances within a single package slot have been |
18 |
>>> pulled !!! into the dependency graph, resulting in a slot conflict: |
19 |
>>> |
20 |
>>> dev-libs/boost:0 |
21 |
>>> |
22 |
>>> (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for |
23 |
>>> merge) pulled in by (no parents that aren't satisfied by other packages |
24 |
>>> in this slot) |
25 |
>>> |
26 |
>>> (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for |
27 |
>>> merge) pulled in by dev-libs/boost:0/1.55.0= required by |
28 |
>>> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed) |
29 |
>>> ^^^^^^^^^^ (and 2 more with the same problem) |
30 |
>>> |
31 |
>>> dev-util/boost-build:0 |
32 |
>>> |
33 |
>>> (dev-util/boost-build-1.55.0:0/0::gentoo, installed) pulled in by |
34 |
>>> =dev-util/boost-build-1.55* required by |
35 |
>>> (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge) |
36 |
>>> ^ |
37 |
>>> ^^^^^ |
38 |
>>> |
39 |
>>> (dev-util/boost-build-1.56.0:0/0::gentoo, ebuild scheduled for merge) |
40 |
>>> pulled in by =dev-util/boost-build-1.56* required by |
41 |
>>> (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge) |
42 |
>>> ^ |
43 |
>>> ^^^^^ |
44 |
>>> |
45 |
>>> media-video/ffmpeg:0 |
46 |
>>> |
47 |
>>> (media-video/ffmpeg-2.6.3:0/54.56.56::gentoo, ebuild scheduled for |
48 |
>>> merge) pulled in by (no parents that aren't satisfied by other packages |
49 |
>>> in this slot) |
50 |
>>> |
51 |
>>> (media-video/ffmpeg-2.2.14:0/52.55.55::gentoo, installed) pulled in by |
52 |
>>> media-video/ffmpeg:0/52.55.55=[vdpau] required by |
53 |
>>> (media-libs/mlt-0.9.0:0/0::gentoo, installed) |
54 |
>>> ^^^^^^^^^^^ |
55 |
>> These are unimportant, it is simply portage telling you it is not |
56 |
>> updating some packages to the latest available and why. Personally, I |
57 |
>> believe this sort of output should only be shown when using --verbose. |
58 |
> |
59 |
> Really? |
60 |
> |
61 |
> That doesn't seem to be at all what it says. It says, with huge |
62 |
> exclamation marks even: |
63 |
> |
64 |
> |
65 |
> "!!! Multiple package instances within a single package slot have been |
66 |
> pulled !!! into the dependency graph, resulting in a slot conflict:" |
67 |
> |
68 |
> |
69 |
> So obviously, something terrible is going on, preventing you from |
70 |
> installing required packages, and there is a dependency conflict which |
71 |
> cannot be solved because only one package of many can be used while |
72 |
> several are required in its place. |
73 |
> |
74 |
> If this is irrelevant, then why doesn't it say that it is irrelevant? |
75 |
> Why was suggested that I remove boost to resolve an irrelevant conflict? |
76 |
> |
77 |
> Should I always ignore such messages? |
78 |
|
79 |
No, you should not ignore such messages. They are printed for a reason. |
80 |
|
81 |
You have a SLOT conflict and whether that prevents you from proceeding |
82 |
or not doesn't change the fact that portage knows you have that conflict. |
83 |
|
84 |
In your specific case today, I believe portage will simply install the |
85 |
lesser version and be done with it, but it will only do that when you |
86 |
fix the USE issue (a whole separate issue) |
87 |
|
88 |
|
89 |
> |
90 |
> |
91 |
>> [...] |
92 |
>>> |
93 |
>>> !!! The ebuild selected to satisfy "sci-libs/hdf5" has unmet |
94 |
>>> requirements. |
95 |
>>> - sci-libs/hdf5-1.8.14-r1::gentoo USE="cxx fortran threads zlib -debug |
96 |
>>> -examples -fortran2003 -mpi -static-libs -szip" |
97 |
>>> |
98 |
>>> The following REQUIRED_USE flag constraints are unsatisfied: |
99 |
>>> threads? ( !cxx !fortran ) |
100 |
>> |
101 |
>> This is blocking you and the reason is given, if you have the threads |
102 |
>> flag on, cxx and fortran must be off. You have both threads and cxx on |
103 |
>> which won't work. |
104 |
> |
105 |
> Well, it doesn't say which of the problems that have been reported are |
106 |
> the ones preventing me from going any further. |
107 |
|
108 |
The USE conflict for sure. Maybe the SLOT conflict but I think portage |
109 |
will just deal with that one |
110 |
|
111 |
> When I get error |
112 |
> messages, especially ones that appear to be very important (see all the |
113 |
> exclamation marks?), I usually try to find out what the problem is and |
114 |
> try to fix it, and starting with the important ones is one possible |
115 |
> approach. That approach seems to be quite reasonable in this case, |
116 |
> considering that I'm trying to upgrade and get messages which appear to |
117 |
> be extremely important /and/ which tell me that I cannot upgrade, thus |
118 |
> apparently proving that their importance is more than merely apparent. |
119 |
> |
120 |
> Then someone comes along and says that the messages with double-apparent |
121 |
> importance are actually irrelevant. I find that very funny :) Is that |
122 |
> a general thing with Gentoo, that something is the less important the |
123 |
> more important it seems to be, and that something that doesn't seem to |
124 |
> be important at all is the most important? |
125 |
> |
126 |
> This one doesn't look very important, or does it? |
127 |
|
128 |
Chill dude, seriously. The sky is not about to fall on your head and the |
129 |
bits on your disk are not going to miraculously re-arrange themselves |
130 |
into Windows just because you can't do this update. |
131 |
|
132 |
Portage is what it is, deal with it. |
133 |
|
134 |
The portage team are all unpaid volunteers just liek everyone else and |
135 |
none of us have any right at all to make demands of them. Especially not |
136 |
you and I who are not active contribution solutions. |
137 |
|
138 |
> |
139 |
>>> Why can't we just update like we can with any other distribution but |
140 |
>>> have to run into dependency problems all the time instead? |
141 |
>> |
142 |
>> These aren't dependency problems, they are conflicting USE flags, a |
143 |
>> situation that cannot arise with a binary distro. If you want the |
144 |
>> flexibility that USE flags offer, you have to accept that not all |
145 |
>> combinations will work together. |
146 |
> |
147 |
> That's fine --- I know I need to look into the USE flags here, the |
148 |
> message is somewhat clear. I pasted it only for the sake of |
149 |
> completeness. |
150 |
> |
151 |
> And I appreciate that kind of choice very much, to the point where I |
152 |
> don't really see a way back to binary distributions. They don't make |
153 |
> sense anymore, though they still have their uses. |
154 |
> |
155 |
>>> What do I do when I need to update /right now/ and find myself being |
156 |
>>> blocked with cryptic messages like the above that leave me stranded? |
157 |
>> |
158 |
>> That's the real problem, that the messages are so cryptic. The solution |
159 |
>> is simple, working out what needs to be done from the messages is not. |
160 |
> |
161 |
> How about adding comments to such messages, like "You don't need to do |
162 |
> anything to be able to proceed." and "You need to fix this before you |
163 |
> could proceed."? |
164 |
|
165 |
If emerge exited then you need to fix something in your config. |
166 |
If emerge does not exit then your config can be used as-is. |
167 |
|
168 |
|
169 |
> That's probably easy to do and would greatly help to distinguish between |
170 |
> important and irrelevant messages and make it easier to decide which |
171 |
> problem one wants to solve first. |
172 |
> |
173 |
>>> Once I used 'emerge --sync', there is no way to turn it back to continue |
174 |
>>> to be able to install software if needed when the update cannot be |
175 |
>>> performed. Updates simply need to work, there's no way around that. |
176 |
>> |
177 |
>> You can always roll back by masking the updates if necessary, and the |
178 |
>> old ebuilds are always available. Now that the tree is using git, it is |
179 |
>> probably possibly to sync back to yesterday if you need to. |
180 |
> |
181 |
> Something like 'emerge --unsync' or 'emerge --syncto |
182 |
> <particular-git-hash>' would be much easier, taking you back to where |
183 |
> you were before you did an 'emerge --sync', or to when things were at |
184 |
> the particular hash. |
185 |
> |
186 |
> The last sync I did before the one yesterday wasn't the day before |
187 |
> yesterday but over three months ago, so don't ask me today (or next |
188 |
> weekend or whenever I give it another try) when that exactly was. See |
189 |
> what I mean? Asking me to mask all packages to a certain point in time |
190 |
> is like asking me to do much of the package management by myself. |
191 |
|
192 |
Exactly. You DO need to do the package management yourself. The Gentoo |
193 |
devs provide useful tools in the form of portage and the tree with it's |
194 |
ebuilds and eclasses, plus some amazing automation. |
195 |
|
196 |
But, are here's the bit where so many people move away from Gentoo: |
197 |
|
198 |
You are required to do the management yourself, including most of the |
199 |
thinking and all of the sweeping up of broken pieces. That's what you |
200 |
signed up for when using Gentoo. If you want to roll back the tree, then |
201 |
you need to implement a solution that will let you do it as Gentoo does |
202 |
nto provide one. Git now makes this easier. |
203 |
|
204 |
However, tree rollbacks are inadvisable for excellent technical reasons |
205 |
- see if you can figure them out. Better to snapshot your entire system |
206 |
and revert the snapshot if it goes south. |
207 |
|
208 |
|
209 |
> Should I make feature requests? |
210 |
|
211 |
|
212 |
No. See Rich's mail |
213 |
|
214 |
|
215 |
-- |
216 |
Alan McKinnon |
217 |
alan.mckinnon@×××××.com |