I would request another version of collision-protect that notifies users about collisions without stopping emerging process. file type, path, size, md5 would be sufficient. Another way is backing up collided files, notify users and continue emerging.
uhm, why? FEATURES=collision-protect was meant as a QA feature AFAIK, not really targetted for production use. Just my 0.02 SFr.
(In reply to comment #1) > uhm, why? FEATURES=collision-protect was meant as a QA feature AFAIK, not > really targetted for production use. Personally, I don't enable collision-protect because I don't want my merges interrupted. I'm still curious about whether or not collisions occur, however. I suppose we could call it something like "collision-notify", and use the elog system to report collisions.
(In reply to comment #1) > uhm, why? FEATURES=collision-protect was meant as a QA feature AFAIK, not > really targetted for production use. Sorry for too late reply. The reason is that I used collision-protect on a system with lots of manual hack. Most of changes are in /usr/share/locale/vi/LC_MESSAGES/*.mo because I'm also a translator. Most of changes can be discarded but I want to make sure what is discarded (and better keep a backup). So it's not really a production system. It's kind of extending the usage of collision-protect. Zac's "collision-notify" is fine with me.
(In reply to comment #3) > The reason is that I used collision-protect on a system with lots of manual > hack. Most of changes are in /usr/share/locale/vi/LC_MESSAGES/*.mo because I'm > also a translator. Most of changes can be discarded but I want to make sure > what is discarded (and better keep a backup). How about if reuse the CONFIG_PROTECT name mangling scheme for file collisions?
> How about if reuse the CONFIG_PROTECT name mangling scheme for file collisions? Didn't think about that. Yes, it makes sense (with another prefix than ._cfg to prevent confusion of course)
*** Bug 162288 has been marked as a duplicate of this bug. ***
Uhm...FEATURES="collision-protect" is perfectly fine now that all the funky perl stuff doesn't install its manpages. The only "soft" collisions come from badly slotted packages - python-updater and gcc (Bug 136382 and the retarded fix_libtool_files.sh thing) being the major offenders; plus the nasty hardcoded CONFIG_PROTECT on kernel modules (Bug 117972). The last one can be safely worked around by sticking COLLISION_IGNORE="/lib/modules" into make.conf until there's a better solution. Once those are fixed, I'd even suggest this feature should be enabled by default. Getting other packages binaries clobbered by something completely different plain sucks, can cause pretty cryptic bugs and should be always fixed.
*** Bug 184999 has been marked as a duplicate of this bug. ***
As another idea, perhaps there could be a FEATURES option ("collision-binpkg", perhaps) where, whenever a merge is blocked by collision-protect, the freshly compiled program is made into a binpkg so that it can be installed quickly if the collision can be manually verified as spurious.
This has been implemented for some time now.
