Re: [gentoo-user] update problems

[Neil Bothwick <neil@digimed.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 5856 bytes --]

On Sun, 20 Sep 2015 17:28:25 +0200, lee wrote:

> Neil Bothwick <neil@digimed.co.uk> writes:
> > These are unimportant, it is simply portage telling you it is not
> > updating some packages to the latest available and why. Personally, I
> > believe this sort of output should only be shown when using
> > --verbose.   
> 
> Really?
> 
> That doesn't seem to be at all what it says.  It says, with huge
> exclamation marks even:
> 
> 
> "!!! Multiple package instances within a single package slot have been
> pulled !!! into the dependency graph, resulting in a slot conflict:"
> 
> 
> So obviously, something terrible is going on, preventing you from
> installing required packages, and there is a dependency conflict which
> cannot be solved because only one package of many can be used while
> several are required in its place.

A slot conflict is not a dependency conflict.
> 
> If this is irrelevant, then why doesn't it say that it is irrelevant?

Because portage's messages are not as helpful as we would like them to be.

> Why was suggested that I remove boost to resolve an irrelevant conflict?

No idea, the message didn't suggest it.

> Should I always ignore such messages?

You should read them. When a message says "I can't upgrade foo to a newer
version because bar requires the older version" you have no problems
unless something specifically needs the newer foo. Unless the emerge run
stops with blocks (with a capital B) or refuses to otherwise proceed, the
messages are not critical. What has happened here is that you received
these non-critical messages and a critical one, the hdf5 message. At
first glance, the boost messages could be seen as the reason for the
failure to proceed. If in doubt, look at the last message, or those marked
as errors, as the cause of the failure.

> >> !!! The ebuild selected to satisfy "sci-libs/hdf5" has unmet
> >> requirements.
> >> - sci-libs/hdf5-1.8.14-r1::gentoo USE="cxx fortran threads zlib
> >> -debug -examples -fortran2003 -mpi -static-libs -szip"
> >> 
> >>   The following REQUIRED_USE flag constraints are unsatisfied:
> >>     threads? ( !cxx !fortran )  
> >
> > This is blocking you and the reason is given, if you have the threads
> > flag on, cxx and fortran must be off. You have both threads and cxx on
> > which won't work.  
> 
> Well, it doesn't say which of the problems that have been reported are
> the ones preventing me from going any further.  When I get error
> messages, especially ones that appear to be very important (see all the
> exclamation marks?), I usually try to find out what the problem is and
> try to fix it, and starting with the important ones is one possible
> approach.  That approach seems to be quite reasonable in this case,
> considering that I'm trying to upgrade and get messages which appear to
> be extremely important /and/ which tell me that I cannot upgrade, thus
> apparently proving that their importance is more than merely apparent.

See above. You are receiving multiple, unrelated messages, not all of
which are related to the failure to upgrade.

> Then someone comes along and says that the messages with double-apparent
> importance are actually irrelevant.  I find that very funny :)

The advice is based on experience but given for free. You are equally
free to follow or ignore it.

> Is that
> a general thing with Gentoo, that something is the less important the
> more important it seems to be, and that something that doesn't seem to
> be important at all is the most important?

The seems part is based on experience in reading portage messages. As
you get more experienced "seems" tends towards "is".
 
> > That's the real problem, that the messages are so cryptic. The
> > solution is simple, working out what needs to be done from the
> > messages is not.  
> 
> How about adding comments to such messages, like "You don't need to do
> anything to be able to proceed." and "You need to fix this before you
> could proceed."?
> 
> That's probably easy to do and would greatly help to distinguish between
> important and irrelevant messages and make it easier to decide which
> problem one wants to solve first.

If it were easy, it would have been done. I find the message frustrating
too, but accept that an improvement is unlikely to appear in the imminent
future. In fact, as portage gets ever cleverer with its dependency
resolution, the message are likely to get more complex before they become
simpler :(

> >> Once I used 'emerge --sync', there is no way to turn it back to
> >> continue to be able to install software if needed when the update
> >> cannot be performed.  Updates simply need to work, there's no way
> >> around that.  
> >
> > You can always roll back by masking the updates if necessary, and the
> > old ebuilds are always available. Now that the tree is using git, it
> > is probably possibly to sync back to yesterday if you need to.  
> 
> Something like 'emerge --unsync' or 'emerge --syncto
> <particular-git-hash>' would be much easier, taking you back to where
> you were before you did an 'emerge --sync', or to when things were at
> the particular hash.

This would make a useful addition to something like demerge, which
currently can roll back to previous versions, but git should make it
possible to include the tree too.

> The last sync I did before the one yesterday wasn't the day before
> yesterday but over three months ago, so don't ask me today (or next
> weekend or whenever I give it another try) when that exactly was.

Why not, the information is in the logs, and can be extracted with genlop
-r or qlop -s (emerge genlop or portage-utils respectively).


-- 
Neil Bothwick

Nymphomania-- an illness you hear about but never encounter.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]