Created attachment 428354 [details] emerge log Weird breakage can occur if portage doesn't support the new EAPI 6, for example. I just tried to emerge -u @world, and it failed to resolve a dependency for a Perl package, causing it to attempt to unmask an unstable slotted perl. Details attached.
Michael we still need a version of portage, there are many
(In reply to Ian Delaney from comment #1) > Michael we still need a version of portage, there are many All existing portage versions (with EAPI support) are the same in this regarde. It already *strongly* suggests to update portage immediately after emerge --sync. However, if someopne fails to take that suggestion and then hits an EAPI mask, it likely means that they are *really* clueless and could benefit from yet another suggestion.
We can trigger a message if all of the following are true: * emerge arguments do not contain an atom that matches sys-apps/portage * an ebuild with unsupported EAPI has been encountered
(In reply to Ian Delaney from comment #1) > Michael we still need a version of portage, there are many Ian, clearly you didn't look at the emerge log - the details are clearly visible in there. (In reply to Zac Medico from comment #3) That would seem to make sense. I'm not entirely sure why I didn't pick up the update to portage at --sync stage, possibly because there were other messages which otherwise masked it. If, at least, portage was queued as the first update, then you'd be ok going onwards. Your suggestion would, as you state, make a fool-proof solution, so that no matter the circumstances, this rather unexpected behaviour would, at least, be trapped!
(In reply to Michael Everitt (veremit) from comment #4) > If, at least, portage was queued as the first update, then you'd be ok going > onwards. That's what emerge tried to do in older versions of portage, but it has since been abandoned. It's an error-prone path, since portage can't always be installed first, because it may have dependencies that are not yet satisfied. Finally, even if portage can be installed as the first update, EAPI 6 support won't be available until the *next* emerge run. Of course, we could have emerge restart itself, but that's also an error-prone path (see bug 390819).
Thanks for the clarification Zac. Is the change likely to be easy to back-port to previous versions of portage? Just thinking of a way to prevent this particular scenario from occuring again, or mitigating it for users who may not be able to update easily, perhaps.
This seems to be popping up all over the place, seen it today once in real life (laptop of a colleague), then here https://forums.gentoo.org/viewtopic-p-7899600.html
Any progress on this? Just got bitten by it once again .. same symptoms, perl module using EAPI 6 breaks older portage. I didn't see any message to update portage on --sync, but there was definitely an update available when I tried, after finding the EAPI issue directly emerging the Perl package.
As Micheal Everitt, I ran into this problem. Same symptoms, no message about a portage update after syncing. I always check carefully for this, but this happened twice so far I never got the message and there was actually an update to portage. How do we recover from such a situation? I am stuck with the following dependencies issues. x11-libs/libxcb:0 (x11-libs/libxcb-1.12:0/1.12::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (x11-libs/libxcb-1.11.1:0/1.11.1::gentoo, installed) pulled in by >=x11-libs/libxcb-1.9.1:0/1.11.1=[abi_x86_64(-)] required by (x11-libs/xcb-util-0.4.0:0/0::gentoo, installed) ^^^^^^^^^^ (and 6 more with the same problem) dev-libs/gmp:0 (dev-libs/gmp-6.1.0:0/10.4::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (dev-libs/gmp-6.0.0a:0/0::gentoo, installed) pulled in by dev-libs/gmp:0/0= required by (dev-python/gmpy-2.0.4:2/2::gentoo, installed) ^^^^^ (and 2 more with the same problem) dev-lang/perl:0 (dev-lang/perl-5.22.2:0/5.22::gentoo, ebuild scheduled for merge) pulled in by =dev-lang/perl-5.22* required by (virtual/perl-JSON-PP-2.273.0-r1:0/0::gentoo, installed) ^ ^^^^^ dev-lang/perl (Argument) (and 17 more with the same problems) (dev-lang/perl-5.20.2:0/5.20::gentoo, installed) pulled in by dev-lang/perl:0/5.20=[-build(-)] required by (dev-perl/libwww-perl-6.150.0:0/0::gentoo, installed) ^^^^^^^^ =dev-lang/perl-5.20* required by (virtual/perl-Compress-Raw-Zlib-2.65.0:0/0::gentoo, installed) ^ ^^^^^ (and 218 more with the same problems) media-libs/giflib:0 (media-libs/giflib-5.1.4:0/7::gentoo, ebuild scheduled for merge) pulled in by >=media-libs/giflib-5.1.2:= required by (dev-dotnet/libgdiplus-4.2-r2:0/0::gentoo, ebuild scheduled for merge) ^^ ^^^^^ (media-libs/giflib-4.1.6-r3:0/0::gentoo, installed) pulled in by media-libs/giflib:0/0= required by (sci-libs/gdal-2.0.2-r1:0/2::gentoo, installed) ^^^^^ <media-libs/giflib-5 required by (media-libs/libafterimage-1.20:0/0::gentoo, installed) ^ ^ (and 4 more with the same problems)
(In reply to Daniel Savard from comment #9) > How do we recover from such a situation? I am stuck with the following > dependencies issues. Please direct questions like this to forums.gentoo.org. Since you are seeing a lot of conflicts involving built slot operator deps, it's a good idea to use --ignore-built-slot-operator-deps=y together with --pretend in order to temporarily suppress noise related to build slot operators. Hopefully that will allow you to see what other issues are preventing the dependencies from solving. There are plans to reduce built slot operator noise automatically, as discussed in bug 598503.
