On 12/09/17 08:18, John Covici wrote:
On Sat, 09 Dec 2017 10:28:25 -0500,
Daniel Frey wrote:
I had a lot of problems with the perl updates as well, and could
not get it to resolve. I wasted over an hour trying to resolve it
(my poor Celeron would take 5-10 minutes trying to calculate
dependencies, and I had to do this 6-7 times.)
Note, what I did worked for me and may not work for you, so use
this advice at your own risk: I emerged the new perl with
--nodeps, and invoked `perl-cleaner all` to fix the mess
afterwards. It had everything resolved in < 10 minutes. I didn't
suffer any system breakage from using the sledgehammer approach,
but others may not be so lucky... so, as I said, try it at your
own risk.
I was thinking of just that myself, I may try that later today. I am
using zfs, and do snapshots frequently, so it might be possible to get
back if things are a disaster, but it might work at that. Did you
emerge perl again without the --nodeps afterwards to make sure?
Well, due to the long compile times I was trying to get the dependencies
resolved so I could run `emerge -auDNe world --exclude sys-devel/gcc
--exclude sys-devel/llvm --exclude sys-devel/libtool --exclude
sys-devel/binutils --exclude sys-libs/glibc --keep-going world` so it
would recompile everything and update as it went along. (I had already
built the excluded packages under the new profile with gcc6.)
While I didn't remerge perl immediately after, it was included in the
rebuild process of --emptytree.
And it was successful! I only had perl blocking everything, so once I
sledgeammered that update, it was able to calculate its dependency list,
and it rebuilt all 500 installed packages (well, less the ones I
excluded) successfully - no failed packages or anything, while upgrading
as needed. It did take almost 30 hours though.
When trying to get perl blockers to resolve I even tried --backtrack=200
and it still failed. That was try 5 or 6 and at that point I was getting
annoyed and tried the sledgehammer technique.
Dan
