I ran into bug 253702 today and did FEATURES="-collision-protect" emerge -1 linux-headers to install the header files despite the collision, but Portage bails out despite being told not to.
FEATURES="protect-owned" is enabled by default.
Thanks for the information Arfrever, I wasn't aware of this new feature. A few remarks: - Users of the stable tree deserve a short notice about this behaviour change. - I probably would have found the information myself, if I would have thought about make.conf.example and the make.conf man page being out of sync for as long as I can remember. One source to create both files would be nice. - It feels a bit odd that providing -collision-protect on the command line doesn't trump protect-owned, given that it's the stronger feature of both. But asking for a tri-state here (unset, on, off) doesn't really fit into our feature flag handling and disabling protect-owned is already done, so... - Regarding this feature itself, I'm not fond of it at all. When there are lots of "orphans" for whatever reason, it's a lot better users are aware of it and disable the collision-protect feature temporarily after inspecting the issue at hand; I see no point in feeding lazy folks. protect-owned not only asks for problems on systems where Portage is used on top of other distributions, but also may destroy evidence in case of a hacked system.
(In reply to comment #2) > - Regarding this feature itself, I'm not fond of it at all. When there are lots > of "orphans" for whatever reason, it's a lot better users are aware of it and > disable the collision-protect feature temporarily after inspecting the issue at > hand; I see no point in feeding lazy folks. protect-owned not only asks for > problems on systems where Portage is used on top of other distributions, but > also may destroy evidence in case of a hacked system. It's not about "feeding lazy folks". It's about the tremendous backlash that I'd get if I enabled collision-protect by default. The fact is that the majority of users have orphans on their system for various reasons. For these users, bailing out due to a collision with an orphan file would be a 'false positive' in most cases. It would lead to lots of unhappy users and I don't want to deal with the complaints it would trigger. As for 'destroying evidence of a hacked system', it's not any worse than it was before protect-owned was enabled by default. So, it's really not any worse than before, and there are obvious benefits (solves bug 195527).
Here's what I've done: - added ewarn message to the ebuild - removed collision-protect from the make.conf.example since most users will probably just use protect-owned which is enabled by default now - added note to RELEASE-NOTES file about the need to disable both features in if you want to completely disable collision protection This is what the ewarn message looks like: * * File collision protection is now enabled by default via make.globals * with FEATURES=protect-owned. If you want to disable collision * protection completely (not recommended), then you need to ensure * that neither protect-owned nor collision-protect are enabled. *
(In reply to comment #3) > It's not about "feeding lazy folks". It's about the tremendous backlash that > I'd get if I enabled collision-protect by default. Is it really that bad!? I've been using the collision-protect feature since its existence and while I'm aware that there have been a number of issues, I'm still inclined to think, that mostly users playing with Portage's more dirty features get hit. On the other hand, I've no machines running with development versions of Portage or early release candidates, maybe this makes a difference. > It would lead to lots of unhappy users and I don't want to deal with the complaints it would trigger. True, but on the other hand issues as in bug 195527, which partly can be considered to be broken Portage behaviour as well as human error, because of package maintainers sometimes not being aware of Portage's behaviour in such edge cases. Another source of such errors is the everything else than seldom, but broken advice to use Portage's --nodeps feature to bypass hard blockers - and it would be an improvement, if future Portage versions would disallow this. Thank you for adding some information regarding this behaviour change.
(In reply to comment #5) > (In reply to comment #3) > > It's not about "feeding lazy folks". It's about the tremendous backlash that > > I'd get if I enabled collision-protect by default. > > Is it really that bad!? I've been using the collision-protect feature since its > existence and while I'm aware that there have been a number of issues, I'm > still inclined to think, that mostly users playing with Portage's more dirty > features get hit. On the other hand, I've no machines running with development > versions of Portage or early release candidates, maybe this makes a difference. It's just that most users would consider a collision with an orphan file a "false positive". Having portage bail out in such cases (by default) would make too many people unhappy. The new protect-owned feature solves this problem nicely, by eliminating "false positives". > > It would lead to lots of unhappy users and I don't want to deal with the complaints it would trigger. > > True, but on the other hand issues as in bug 195527, which partly can be > considered to be broken Portage behaviour as well as human error, because of > package maintainers sometimes not being aware of Portage's behaviour in such > edge cases. Another source of such errors is the everything else than seldom, > but broken advice to use Portage's --nodeps feature to bypass hard blockers - > and it would be an improvement, if future Portage versions would disallow this. It would be nice to cover up the --nodeps hole, but I think that would upset people who expect --nodeps to really disable all dependency handling. At least with FEATURES=protect-owned enabled by default now, emerge will bail out due to file collisions when they use --nodeps. That should discourage people from using it to get around blockers.
(In reply to comment #4) > Here's what I've done: > > - added ewarn message to the ebuild > - removed collision-protect from the make.conf.example since most users will > probably just use protect-owned which is enabled by default now > - added note to RELEASE-NOTES file about the need to disable both features in > if you want to completely disable collision protection This stuff is all in 2.1.6.5.
