Yikes, road bump. I just got done with my “emerge world” (yes 5 days later [overnights a slow pc]) and did a –depclean. I got hit bad by this block on day two:
[blocks B ] sys-apps/mktemp (is blocking sys-apps/coreutils-6.10-r1) [blocks B ] >=sys-apps/coreutils-6.10 (is blocking sys-apps/mktemp-1.5)
Unemerging coreutils to let in mktemp was a bad idea. Bye bye ls, mv, mkdir… oh boy. Thank god the net was still up and I was able search, discover and extract what I needed from a stage3 to be able to build coreutils. Fast forward to today and –depclean removed “mktemp“. This took down my network connection. I had to encourage a librarian to burn mktemp source to a disk, and had thank the lord emerge didn’t fail. It didn’t. I blame udept for the –depclean fiasco. But now my pc is up to date… almost almost.
Ouch..When I hit that yesterday, I just checked the coreutils ebuild and and (correctly) assumed that it replaced mktemp. Unmerged mktemp and updated coreutils and all was well. And yes, udept’s “–depclean” equivalent is kind of broken for me as well, so I just use the old-fasioned way.
You might find the “What are blocks used for?” thread on gentoo-dev interesting. Link in the URL thing.
Hehe I had googled out when I recd. this and the forums did help, I chose the new coreutils over mktemp and all was fine :P
But then again, I got on to the shame of wall for unmerging gcc yesterday. :(
Ouch indeed. My sympathies. This is one of many cases where Portage hands you a loaded gun pointed at your foot and kindly puts your finger on the trigger for you.
Not just portage, I ran into the same thing with paludis. In fact, I have coreutils in package_mask now.