simple example to demonstrate collision-protects miss (in this case not a horrible miss)- merge net-libs/liblockfile-1.06-r1 note in the contents no /usr/lib/liblockfile.so.1 entry, and that the file exists on disk (ldconfig creates it) upgrade to net-libs/liblockfile-1.06-r2 Note it merged that sym, thus stomping a fsentry that it couldn't find an owner to Now... realize that's not necessarily a bad thing at first glance there; but the check itself (near as I can figure) was written to *only* exclude sym overwrites involving directories. The problem is, say dev-util/test merges /usr/lib/libcfile.so.0.0.0 dev-util/test-foo merges a symlink of /usr/lib/l -> /usr/lib/foo, and merges /usr/lib/libcfile.so.0.0.0 portage's collision-protect will not pick this up, because the dir exemption doesn't limit itself to _just_ directories- it behaves such that any fs entry that matches the initial path of a symlink is automatically exempted. Personally, I like my system, but I strongly suspect merging a sym of /u -> /foo would disable all collision detection for /u* matches, which is bad; very least, example given above of where it screw up... Reproducible: Always Steps to Reproduce:
Thanks. I've applied a minimal fix in svn r5499.
This has been released in 2.1.2_rc4-r8.
