When more than one package does PROVIDE="virtual/xyz", and some other package depends on virtual/xyz, then it will be somewhat random which package "emerge --depclean" will believe satisifes the dependency. Hence, it will be somewhat random whether "emerge --depclean" believes that a package is not needed. In my case, this arises with mail-mta/ssmtp and mail-mta/nullmailer, both of which do PROVIDE="virtual/mta". I have mail-mta/nullmailer in /var/lib/portage/world, because it is the one I am actively using. I have not yet bothered to uninstall mail-mta/ssmtp. There is at least one needed package that depends on virtual/mta (e.g., in my case sys-process/vixie-cron depends on it). As a result, "emerge --pretend --depclean world" randomly either does or does not report mail-mta/ssmtp as being unneeded. (This also affects net-mail/mailbase, because on my system it is only depended on by mail-mta/ssmtp.) In my case, the only problem caused is that some packages are sometimes randomly not being detected as unneeded. However, if I didn't have mail-mta/nullmailer in /var/lib/portage/world, I think the problem would be more serious and "emerge --depclean" would half of the time be thinking that mail-mta/nullmailer should be removed. It is not clear to me that this problem can be easily fixed within the current framework. How is emerge supposed to know which of two packages providing virtual/xyz is the one that is really needed? Perhaps it should simply be conservative and assume that all packages providing virtual/xyz might really be needed? Of course this defeats the goal of "emerge --depclean" which is to remove obsolete cruft, but perhaps this case is simply too complicated to safely handle by automated means. Even if it is not obvious how to fix this now, I think this bug report could be useful input to anyone considering a redesign of the idea of "emerge --depclean". Despite involving both ssmtp and mailbase, I am pretty sure this is _not_ a duplicate of bug 9941 and/or bug 9779.
Created attachment 88760 [details] Output of "emerge -info" on my system.
*** Bug 139877 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > Perhaps it should simply be conservative and assume that all packages > providing virtual/xyz might really be needed? That's what I've done in svn r3986 and it's available in >=portage-2.1.1_pre3-r4.
*** Bug 150716 has been marked as a duplicate of this bug. ***
*** Bug 151403 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > (In reply to comment #0) > > Perhaps it should simply be conservative and assume that all packages > > providing virtual/xyz might really be needed? > > That's what I've done in svn r3986 and it's available in > >=portage-2.1.1_pre3-r4. Apparently I reverted that change a while back. I think the best solution for this bug is to simply add anything you want to keep to the world file. I don't see any reason for depclean to be conservative with virtuals or even || ( ) dependencies for that matter. The world file seems like an ideal way to declare the packages that you never want to have removed by depclean. The packages that depclean removes are the same ones that `emerge --deep world` won't update. Either unmerge them or add them to world and the problem is solved.
