On 20/09/2015 17:28, lee wrote: > Neil Bothwick <[email protected]> writes: > >> On Sat, 19 Sep 2015 21:36:06 +0200, lee wrote: >> >>> emerge -j 8 -a --update --newuse --deep --with-bdeps=y >>> @world >>> >>> >>> >>> * IMPORTANT: 4 news items need reading for repository 'gentoo'. >>> * Use eselect news read to view new items. >>> >>> >>> These are the packages that would be merged, in order: >>> >>> Calculating dependencies... done! >>> >>> !!! Multiple package instances within a single package slot have been >>> pulled !!! into the dependency graph, resulting in a slot conflict: >>> >>> dev-libs/boost:0 >>> >>> (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for >>> merge) pulled in by (no parents that aren't satisfied by other packages >>> in this slot) >>> >>> (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for >>> merge) pulled in by dev-libs/boost:0/1.55.0= required by >>> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed) >>> ^^^^^^^^^^ (and 2 more with the same problem) >>> >>> dev-util/boost-build:0 >>> >>> (dev-util/boost-build-1.55.0:0/0::gentoo, installed) pulled in by >>> =dev-util/boost-build-1.55* required by >>> (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge) >>> ^ >>> ^^^^^ >>> >>> >>> (dev-util/boost-build-1.56.0:0/0::gentoo, ebuild scheduled for merge) >>> pulled in by =dev-util/boost-build-1.56* required by >>> (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge) >>> ^ >>> ^^^^^ >>> >>> >>> media-video/ffmpeg:0 >>> >>> (media-video/ffmpeg-2.6.3:0/54.56.56::gentoo, ebuild scheduled for >>> merge) pulled in by (no parents that aren't satisfied by other packages >>> in this slot) >>> >>> (media-video/ffmpeg-2.2.14:0/52.55.55::gentoo, installed) pulled in by >>> media-video/ffmpeg:0/52.55.55=[vdpau] required by >>> (media-libs/mlt-0.9.0:0/0::gentoo, installed) >>> ^^^^^^^^^^^ >>> >> 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. > > If this is irrelevant, then why doesn't it say that it is irrelevant? > Why was suggested that I remove boost to resolve an irrelevant conflict? > > Should I always ignore such messages?
No, you should not ignore such messages. They are printed for a reason. You have a SLOT conflict and whether that prevents you from proceeding or not doesn't change the fact that portage knows you have that conflict. In your specific case today, I believe portage will simply install the lesser version and be done with it, but it will only do that when you fix the USE issue (a whole separate issue) > > >> [...] >>> >>> !!! 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. The USE conflict for sure. Maybe the SLOT conflict but I think portage will just deal with that one > 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. > > Then someone comes along and says that the messages with double-apparent > importance are actually irrelevant. I find that very funny :) 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? > > This one doesn't look very important, or does it? Chill dude, seriously. The sky is not about to fall on your head and the bits on your disk are not going to miraculously re-arrange themselves into Windows just because you can't do this update. Portage is what it is, deal with it. The portage team are all unpaid volunteers just liek everyone else and none of us have any right at all to make demands of them. Especially not you and I who are not active contribution solutions. > >>> Why can't we just update like we can with any other distribution but >>> have to run into dependency problems all the time instead? >> >> These aren't dependency problems, they are conflicting USE flags, a >> situation that cannot arise with a binary distro. If you want the >> flexibility that USE flags offer, you have to accept that not all >> combinations will work together. > > That's fine --- I know I need to look into the USE flags here, the > message is somewhat clear. I pasted it only for the sake of > completeness. > > And I appreciate that kind of choice very much, to the point where I > don't really see a way back to binary distributions. They don't make > sense anymore, though they still have their uses. > >>> What do I do when I need to update /right now/ and find myself being >>> blocked with cryptic messages like the above that leave me stranded? >> >> 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."? If emerge exited then you need to fix something in your config. If emerge does not exit then your config can be used as-is. > 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. > >>> 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. > > 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. See > what I mean? Asking me to mask all packages to a certain point in time > is like asking me to do much of the package management by myself. Exactly. You DO need to do the package management yourself. The Gentoo devs provide useful tools in the form of portage and the tree with it's ebuilds and eclasses, plus some amazing automation. But, are here's the bit where so many people move away from Gentoo: You are required to do the management yourself, including most of the thinking and all of the sweeping up of broken pieces. That's what you signed up for when using Gentoo. If you want to roll back the tree, then you need to implement a solution that will let you do it as Gentoo does nto provide one. Git now makes this easier. However, tree rollbacks are inadvisable for excellent technical reasons - see if you can figure them out. Better to snapshot your entire system and revert the snapshot if it goes south. > Should I make feature requests? No. See Rich's mail -- Alan McKinnon [email protected]
