1 |
On Sun, 20 Sep 2015 17:28:25 +0200, lee wrote: |
2 |
|
3 |
> Neil Bothwick <neil@××××××××××.uk> writes: |
4 |
> > These are unimportant, it is simply portage telling you it is not |
5 |
> > updating some packages to the latest available and why. Personally, I |
6 |
> > believe this sort of output should only be shown when using |
7 |
> > --verbose. |
8 |
> |
9 |
> Really? |
10 |
> |
11 |
> That doesn't seem to be at all what it says. It says, with huge |
12 |
> exclamation marks even: |
13 |
> |
14 |
> |
15 |
> "!!! Multiple package instances within a single package slot have been |
16 |
> pulled !!! into the dependency graph, resulting in a slot conflict:" |
17 |
> |
18 |
> |
19 |
> So obviously, something terrible is going on, preventing you from |
20 |
> installing required packages, and there is a dependency conflict which |
21 |
> cannot be solved because only one package of many can be used while |
22 |
> several are required in its place. |
23 |
|
24 |
A slot conflict is not a dependency conflict. |
25 |
> |
26 |
> If this is irrelevant, then why doesn't it say that it is irrelevant? |
27 |
|
28 |
Because portage's messages are not as helpful as we would like them to be. |
29 |
|
30 |
> Why was suggested that I remove boost to resolve an irrelevant conflict? |
31 |
|
32 |
No idea, the message didn't suggest it. |
33 |
|
34 |
> Should I always ignore such messages? |
35 |
|
36 |
You should read them. When a message says "I can't upgrade foo to a newer |
37 |
version because bar requires the older version" you have no problems |
38 |
unless something specifically needs the newer foo. Unless the emerge run |
39 |
stops with blocks (with a capital B) or refuses to otherwise proceed, the |
40 |
messages are not critical. What has happened here is that you received |
41 |
these non-critical messages and a critical one, the hdf5 message. At |
42 |
first glance, the boost messages could be seen as the reason for the |
43 |
failure to proceed. If in doubt, look at the last message, or those marked |
44 |
as errors, as the cause of the failure. |
45 |
|
46 |
> >> !!! The ebuild selected to satisfy "sci-libs/hdf5" has unmet |
47 |
> >> requirements. |
48 |
> >> - sci-libs/hdf5-1.8.14-r1::gentoo USE="cxx fortran threads zlib |
49 |
> >> -debug -examples -fortran2003 -mpi -static-libs -szip" |
50 |
> >> |
51 |
> >> The following REQUIRED_USE flag constraints are unsatisfied: |
52 |
> >> threads? ( !cxx !fortran ) |
53 |
> > |
54 |
> > This is blocking you and the reason is given, if you have the threads |
55 |
> > flag on, cxx and fortran must be off. You have both threads and cxx on |
56 |
> > which won't work. |
57 |
> |
58 |
> Well, it doesn't say which of the problems that have been reported are |
59 |
> the ones preventing me from going any further. When I get error |
60 |
> messages, especially ones that appear to be very important (see all the |
61 |
> exclamation marks?), I usually try to find out what the problem is and |
62 |
> try to fix it, and starting with the important ones is one possible |
63 |
> approach. That approach seems to be quite reasonable in this case, |
64 |
> considering that I'm trying to upgrade and get messages which appear to |
65 |
> be extremely important /and/ which tell me that I cannot upgrade, thus |
66 |
> apparently proving that their importance is more than merely apparent. |
67 |
|
68 |
See above. You are receiving multiple, unrelated messages, not all of |
69 |
which are related to the failure to upgrade. |
70 |
|
71 |
> Then someone comes along and says that the messages with double-apparent |
72 |
> importance are actually irrelevant. I find that very funny :) |
73 |
|
74 |
The advice is based on experience but given for free. You are equally |
75 |
free to follow or ignore it. |
76 |
|
77 |
> Is that |
78 |
> a general thing with Gentoo, that something is the less important the |
79 |
> more important it seems to be, and that something that doesn't seem to |
80 |
> be important at all is the most important? |
81 |
|
82 |
The seems part is based on experience in reading portage messages. As |
83 |
you get more experienced "seems" tends towards "is". |
84 |
|
85 |
> > That's the real problem, that the messages are so cryptic. The |
86 |
> > solution is simple, working out what needs to be done from the |
87 |
> > messages is not. |
88 |
> |
89 |
> How about adding comments to such messages, like "You don't need to do |
90 |
> anything to be able to proceed." and "You need to fix this before you |
91 |
> could proceed."? |
92 |
> |
93 |
> That's probably easy to do and would greatly help to distinguish between |
94 |
> important and irrelevant messages and make it easier to decide which |
95 |
> problem one wants to solve first. |
96 |
|
97 |
If it were easy, it would have been done. I find the message frustrating |
98 |
too, but accept that an improvement is unlikely to appear in the imminent |
99 |
future. In fact, as portage gets ever cleverer with its dependency |
100 |
resolution, the message are likely to get more complex before they become |
101 |
simpler :( |
102 |
|
103 |
> >> Once I used 'emerge --sync', there is no way to turn it back to |
104 |
> >> continue to be able to install software if needed when the update |
105 |
> >> cannot be performed. Updates simply need to work, there's no way |
106 |
> >> around that. |
107 |
> > |
108 |
> > You can always roll back by masking the updates if necessary, and the |
109 |
> > old ebuilds are always available. Now that the tree is using git, it |
110 |
> > is probably possibly to sync back to yesterday if you need to. |
111 |
> |
112 |
> Something like 'emerge --unsync' or 'emerge --syncto |
113 |
> <particular-git-hash>' would be much easier, taking you back to where |
114 |
> you were before you did an 'emerge --sync', or to when things were at |
115 |
> the particular hash. |
116 |
|
117 |
This would make a useful addition to something like demerge, which |
118 |
currently can roll back to previous versions, but git should make it |
119 |
possible to include the tree too. |
120 |
|
121 |
> The last sync I did before the one yesterday wasn't the day before |
122 |
> yesterday but over three months ago, so don't ask me today (or next |
123 |
> weekend or whenever I give it another try) when that exactly was. |
124 |
|
125 |
Why not, the information is in the logs, and can be extracted with genlop |
126 |
-r or qlop -s (emerge genlop or portage-utils respectively). |
127 |
|
128 |
|
129 |
-- |
130 |
Neil Bothwick |
131 |
|
132 |
Nymphomania-- an illness you hear about but never encounter. |