Any upgrade/downgrade of package (incl. portage itself) fails with massive collisions (probably every existing file that belongs to previously installed version is reported).
Just an example, trying to downgrade portage: <snip> existing file /etc/env.d/05portage.envd is not owned by this package existing file /usr/lib/python2.4/site-packages/missingos.so is not owned by this package existing file /usr/lib/portage/bin/fixpackages is not owned by this package existing file /usr/lib/portage/bin/domo is not owned by this package existing file /usr/lib/portage/bin/xpak is not owned by this package existing file /usr/lib/portage/bin/fix-db.py is not owned by this package existing file /usr/lib/portage/bin/dolib.so is not owned by this package existing file /usr/lib/portage/bin/env-update is not owned by this package existing file /usr/lib/portage/bin/fixdbentries is not owned by this package existing file /usr/lib/portage/bin/repoman is not owned by this package existing file /usr/lib/portage/bin/dobin is not owned by this package existing file /usr/lib/portage/bin/dodir is not owned by this package existing file /usr/lib/portage/bin/dodoc is not owned by this package existing file /usr/lib/portage/bin/doexe is not owned by this package existing file /usr/lib/portage/bin/dojar is not owned by this package existing file /usr/lib/portage/bin/doins is not owned by this package existing file /usr/lib/portage/bin/dolib is not owned by this package existing file /usr/lib/portage/bin/doman is not owned by this package existing file /usr/lib/portage/bin/dosed is not owned by this package existing file /usr/lib/portage/bin/dosym is not owned by this package existing file /usr/lib/portage/bin/emake is not owned by this package ... (many more) </snip>
Created attachment 84528 [details, diff] svn r3012 I'm not able to reproduce the problem. The only change in the collision-protect code was r3012. Could you revert that patch to see if it helps? http://sources.gentoo.org/viewcvs.py/portage/main/trunk/pym/portage.py?r1=3006&r2=3012
Uh... I've downgraded portage after I filed the above bug. Now I've upgraded again - and it's not happening. WTH??? Well, not reproducible any more, closing.
Hold your horses... Sorry for the noise, guys, but it's back. I've emerge synced, tried to upgrade to new portage release, and - bombs out again - all portage files collide... :S
(In reply to comment #2) > Could you revert that patch to see if it helps? > http://sources.gentoo.org/viewcvs.py/portage/main/trunk/pym/portage.py?r1=3006&r2=3012 Yes, it does solve the issue. After a bunch of failed attempts, I applied the reversed patch and now I could successfully upgrade portage. After that, I tried to re-emerge portage a couple of more times, but again - cannot reproduce the issue now. Well, something's definitely fishy here. :/
And it's back again with portage-2.1_pre8-r3, didn't do anything in between, no emerge --sync or whatever. Just waited a couple of hours, and ran emerge -uD world. existing file /usr/lib/libmng.la is not owned by this package existing file /usr/lib/libmng.a is not owned by this package existing file /usr/include/libmng_conf.h is not owned by this package existing file /usr/include/libmng_types.h is not owned by this package existing file /usr/include/libmng.h is not owned by this package existing file /usr/share/man/man3/libmng.3.gz is not owned by this package existing file /usr/share/man/man5/mng.5.gz is not owned by this package existing file /usr/share/man/man5/jng.5.gz is not owned by this package existing file /usr/lib/debug/usr/lib/libmng.so.1.0.0.debug is not owned by this package existing file /usr/lib/libmng.so is not owned by this package
Created attachment 84618 [details, diff] use the correct cpv for slot comparison This is fixed in svn r3145.
Actually, it's broken still because mysettings["SLOT"] doesn't have the correct value (it's an empty string). I need fix that...
(In reply to comment #8) > Actually, it's broken still because mysettings["SLOT"] doesn't have the correct > value (it's an empty string). I need fix that... Yeah, I just noticed... Any particular reason for the change? (Just asking since reverting it completely using the patch in Comment #2 always works).
(In reply to comment #9) > Yeah, I just noticed... Any particular reason for the change? (Just asking > since reverting it completely using the patch in Comment #2 always works). The change is supposed to allow detection of file collisions between different slots (those types of collisions were previously ignored). Yeah, it's broken, but I'll get it fixed.
Created attachment 84620 [details, diff] save mysettings["SLOT"] from destruction Fixed in r3146. :)
Released in 2.1_pre8-r5.
