On gentoo-user some users have had depclean remove python 2.6 for example, because 2.7 has been installed, but as they have not eselected 2.7 and run python-updater their systems have been broken. Can you please add an additional check to --depclean that verifies that the packages are not still active according to eselect? Reproducible: Always Steps to Reproduce: As above Actual Results: Some level of system breakage. Expected Results: depclean should not remove a package that is eselected
There's already an uninstall protection for the python interpreter from bug 357009, but --depclean support would be a nice enhancement.
Python was used as an example - hopefully a new depclean check can catch anything thats switched via eselect.
Hmm, I’d be happy to see this fixed too, as it is annoying to be forced to add less to the world file to prevent it from getting depcleaned, even though it is apparently in the or somehow required by the system set *and* set via eselect.
(In reply to comment #1) > There's already an uninstall protection for the python interpreter from bug > 357009, but --depclean support would be a nice enhancement. Python check seems to be an exception. To my mind a common solution (for all slotted eselect-managed applications) is wanted. Just as example: bug 432962 (emerge --depclean uninstalls active php interpreter)
*** This bug has been marked as a duplicate of bug 283587 ***
(In reply to comment #5) > > *** This bug has been marked as a duplicate of bug 283587 *** Uum, shouldn’t it be the other way around, since this is the generic bug, and the other is the specific for one case? Will this end in another case of fixing the specific bug, and then disallowing the creation of a new bug for a generic fix, because that bug already exists, and was wrongly marked as a duplicate of the specific one? That’s not a nice way of doing things. Please don’t do that.
