From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id B45061384AE for ; Sun, 20 Sep 2015 16:35:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7D91021C03F; Sun, 20 Sep 2015 16:35:23 +0000 (UTC) Received: from mail.digimed.co.uk (82-69-83-178.dsl.in-addr.zen.co.uk [82.69.83.178]) by pigeon.gentoo.org (Postfix) with ESMTP id 59E6021C00D for ; Sun, 20 Sep 2015 16:35:22 +0000 (UTC) Received: from digimed.co.uk (yooden.digimed.co.uk [192.168.1.6]) by mail.digimed.co.uk (Postfix) with ESMTPA id 7A381186835 for ; Sun, 20 Sep 2015 17:35:21 +0100 (BST) Date: Sun, 20 Sep 2015 17:35:15 +0100 From: Neil Bothwick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] update problems Message-ID: <20150920173515.4d93bceb@digimed.co.uk> In-Reply-To: <87zj0haz52.fsf@heimdali.yagibdah.de> References: <87eghucic9.fsf@heimdali.yagibdah.de> <20150919210527.1930cf41@digimed.co.uk> <87zj0haz52.fsf@heimdali.yagibdah.de> Organization: Digital Media Production X-Mailer: Claws Mail 3.12.0-84-g30ac52 (GTK+ 2.24.28; x86_64-pc-linux-gnu) X-GPG-Fingerprint: 7260 0F33 97EC 2F1E 7667 FE37 BA6E 1A97 4375 1903 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/uI=lLF8WbtEP=20pZKG6ZnM"; protocol="application/pgp-signature" X-Archives-Salt: 709ab99a-f718-4877-99a2-84a8c0c440a7 X-Archives-Hash: 30a46414b2260487d8470e34d94c9499 --Sig_/uI=lLF8WbtEP=20pZKG6ZnM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 20 Sep 2015 17:28:25 +0200, lee wrote: > Neil Bothwick 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. =20 >=20 > Really? >=20 > That doesn't seem to be at all what it says. It says, with huge > exclamation marks even: >=20 >=20 > "!!! Multiple package instances within a single package slot have been > pulled !!! into the dependency graph, resulting in a slot conflict:" >=20 >=20 > 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. >=20 > 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=3D"cxx fortran threads zlib > >> -debug -examples -fortran2003 -mpi -static-libs -szip" > >>=20 > >> The following REQUIRED_USE flag constraints are unsatisfied: > >> threads? ( !cxx !fortran ) =20 > > > > 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. =20 >=20 > 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". =20 > > 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. =20 >=20 > 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."? >=20 > 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. =20 > > > > 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. =20 >=20 > Something like 'emerge --unsync' or 'emerge --syncto > ' 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). --=20 Neil Bothwick Nymphomania-- an illness you hear about but never encounter. --Sig_/uI=lLF8WbtEP=20pZKG6ZnM Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlX+4EMACgkQum4al0N1GQOxXwCcCM2O7qr9slnMtDAu7+NYZHkZ U7IAoJSJWao2Vo6eISULuLc1XfaTPVfb =/bN8 -----END PGP SIGNATURE----- --Sig_/uI=lLF8WbtEP=20pZKG6ZnM--