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
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
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
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
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.