On 29/05/2016 10:13, Mick wrote: > On Sunday 29 May 2016 09:40:10 Alan McKinnon wrote: >> Heads up to any ~arch users who might run into this. >> >> I've just spent too many annoying hours dealing with perl-5.24 and it's >> modules. As usual with recent perl upgrades, many modules have moved >> around and now there's a whole whack of new virtuals. One or more are >> causing problems like this: >> >> !!! Multiple package instances within a single package slot have been pulled >> !!! into the dependency graph, resulting in a slot conflict: >> >> dev-lang/perl:0 >> >> (dev-lang/perl-5.22.2:0/5.22::gentoo, installed) pulled in by >> =dev-lang/perl-5.22* required by >> (virtual/perl-NEXT-0.650.0-r4:0/0::perl-experimental, installed) >> ^ ^^^^^ >> dev-lang/perl:0/5.22=[-build(-)] required by >> (perl-gcpan/GnuPG-0.19:0/0::splog-musicbrainz-mirror, installed) >> ^^^^^^^^ >> (and 435 more with the same problems) >> >> (dev-lang/perl-5.24.0:0/5.24::gentoo, ebuild scheduled for merge) >> pulled in by >> =dev-lang/perl-5.24* required by >> (virtual/perl-Exporter-5.720.0-r1:0/0::gentoo, installed) >> ^ ^^^^^ >> (and 59 more with the same problem) >> >> and portage bails out. >> BUT IT'S NOT A HARD BLOCKER. >> >> I've given up trying to figure this out. Masking perl-5.24 and running >> emerge with "--backtrack=99" gets portage back into a state where it's >> willing to continue. >> >> Perhaps someone else with more patience can figure this one out. > > Are you saying that the usual incantation of perl-cleaner, dep-clean and > @preserved rebuild will not arrive at a working system?
perl-cleaner won't help here. It was run when perl-5.22 was installed, and everything was fixed up just hunky-dory. perl-5.24 isn't installed yet so there's nothing to clean > > There's been another thread a week ago which mentioned a sys-devel/make-4.2 > bug and the recommendation was to emerge perl with MAKEOPTS=-j1. Did you try > this? It's not perl failing to build, it's portage claiming it can't find a clean upgrade path to offer. The merge doesn't start as the dep graph resolution never completes, so MAKEOPTS isn't even in the picture yet. Basically, some modules have been made ready for 5.24 and other's haven't. Normally what happens in this case is portage sees you still need stuff that uses 5.22 so decides to not upgrade perl itself, leaves all the modules at the current version, and gets on with doing the rest of the non-perl upgrades. With this upgrade, emerge itself fails implying that at least one perl module is preventing the system from staying at 5.22 for $reasons. But when I explicity mask 5.24 set set backtrack=99, portage searches and searches and searches and eventually finds a way to complete and still be consistent so the problem can't be a hard blocker. So something is terribly non-optimum about portage's search paths though all these perl modules. -- Alan McKinnon alan.mckin...@gmail.com
