So here's my latest idea: 1. make 'emerge --unmerge' (-C) equivalent to current '--depclean' by default, that is unmerge only if nothing else depends on the package, 2. make 'emerge --unmerge --nodeps' (-CO) equivalent to current '--rage-clean' behavior, that is unmerge listed packages without a warning, 3. we could possibly keep 'emerge --depclean' or deprecate it. Alternatively, we may deprecate 'emerge --depclean package1...' but keep 'emerge --depclean' to unmerge all stale packages. Rationale: high QA standards are the most important advantage of Gentoo, and we should work hard on keeping them as high as possible. Therefore, the 'standard' set of commands should try hard to prevent causing breakages :). Right now, the merge/unmerge behavior is a bit inconsistent -- merge action defaults to respecting dependency tree, unmerge doesn't. After the change, we would have symmetric behavior -- both actions would by default ensure integrity of the dependency tree, and both would have --nodeps argument that disables that. When people explicitly request '--nodeps', we can assume they know what they're doing, and the extra delay seems unnecessary.
Extra question: do we want a news item for that, extra notice during '-C' or both?
(In reply to Michał Górny from comment #1) > Extra question: do we want a news item for that, extra notice during '-C' or > both? Probably both. Also, this might break catalyst or something. We could probably patch it in advance to use --unmerge --nodeps, since I think emerge will already accept that.
That sounds like a good way to upset people and make --unmerge pretty much useless. I'd suggest abusing EMERGE_DEFAULT_OPTS if you want to have more fun, and let us live our boring lives ;)
You need to decide what you want to do in regards to your third point. If --unmerge is going to replace --depclean, I do not see a point in keeping it. Nor do I see a point in keeping --rage-clean if that is made superfluous as well. The proposal does not account for what should happen to --depclean-lib-check. Your rationale does not make sense to me. We do not have high QA standards as far as I can tell. And you seem to have forgotten to include the drawbacks of making this change. While the current behaviour is erratic, people really don't like changes. Have you talked to users about this? Is this something they actually want? I can tell you already that *devs* will *not* like it. Patrick is just a taste of what's to come.
