All mail-mta/ssmtp ebuilds explicitly list virtual/libc as a dependency.
Because virtual/libc is part of the system package set, this is clearly
unnecessary.
In addition, because the explicit dependency is followed by the dependency
resolver, this means that an emerge -e world (for example, after a GCC upgrade)
pulls in glibc and gcc, when the previous emerge -e system has already
re-merged them, leading to a considerably increased merging time due to the
redundant double merge of these big packages.
mail-mta/ssmtp should not depend on virtual/libc.
In addition, if such a thing doesn't exist, a QA rule should automatically
point out packages that are not in the system set but depend on packages in the
system set.
(In reply to comment #0)
> In addition, because the explicit dependency is followed by the dependency
> resolver, this means that an emerge -e world (for example, after a GCC upgrade)
> pulls in glibc and gcc, when the previous emerge -e system has already
> re-merged them, leading to a considerably increased merging time due to the
> redundant double merge of these big packages.
>
This would always happen with -e world; that's why tools like emwrap.sh [1] and
and Guenther's upgrade script [2] were written.
[1] http://forums.gentoo.org/viewtopic-t-282474.html
[2] http://forums.gentoo.org/viewtopic-t-494331.html
Not sure about the dep on virtual/libc in itself; just that removing it would
not solve the above issue.
