On 01/22/2015 10:19, Peter Stuge wrote: > Joshua Kinard wrote: >> Using seed stage3 stages I built 6 months ago (but never released due >> to getting sidetracked), I run into errors 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.20.1-r4:0/5.20::gentoo, ebuild scheduled for merge) >> pulled in by >> =dev-lang/perl-5.20* required by >> (virtual/perl-ExtUtils-ParseXS-3.240.0:0/0::gentoo, ebuild scheduled for >> merge) >> ^ ^^^^^ >> (and 16 more with the same problem) >> >> (dev-lang/perl-5.18.2-r2:0/5.18::gentoo, ebuild scheduled for merge) >> pulled in by >> dev-lang/perl:0/5.18=[-build(-)] required by >> (dev-perl/libintl-perl-1.230.0:0/0::gentoo, installed) >> ^^^^^^^^ >> =dev-lang/perl-5.18* required by >> (virtual/perl-ExtUtils-Manifest-1.630.0-r1:0/0::gentoo, installed) >> ^ ^^^^^ >> (and 2 more with the same problems) >> >> It's hard to read mess like that and trace down the offending package, >> fix it, and make catalyst happy. > > Lots of dev-perl packages have specific minor version dependencies on > dev-lang/perl, maybe because sometimes the package is included in perl > and sometimes not. It's a f*ing mess. You have to look up all your > installed dev-perl packages manually and find which ones are either > too old to know about perl-5.20 or not compatible with it, and then > you have to unmerge those manually.
In the past, it's been possible to have Portage deal with the updates to Perl, but only as long as you hit all of the packages in the same update run to satisfy the dependency chain. Newer portage seems to not do that anymore. But that output is horrible. Even with the color coding, it's not directly apparent which package is the problem package. I once had a Perl update issue bad enough that I removed all perl packages entirely, then remerged them from scratch. Took a while, but it fixed things. >> Kinda defeats the purpose of catalyst in the first place. > > The proper way is to build stage1+2+3 yourself, then this mess > doesn't happen. But like you I too cheat a little, and have to deal > with the mess. Well, I was trying to do it the right way by going stage1 -> stage2 -> stage3. I was using a stage3 that I built over the summer as the seed stage for the new stage1 when I started running into problems with Perl. I finally fixed that, got stage1 built, then got bit by Bug #447126 while trying to build the stage2. So now, I have to start a stage2 run, then after the unpack (but before catalyst drops into the chroot), edit the chroot's make.conf and remove sandbox from FEATURES, which is apparently part of the problem. Just irritating. And I know I'm earning no sympathy when I point out that my build machines (an Octane and an Onyx2) aren't the fastest things on the planet, nor the most power efficient (1 kW between the both of them). But I'd at least like to waste that power on actual compile jobs, not watching emerge's little spinner all the time as I try to fix various dependency bugs or other oddities that seemingly came out of nowhere (because the summertime stage runs were flawless in execution). -- Joshua Kinard Gentoo/MIPS [email protected] 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
