[avenj@cerberus avenj]$ qpkg -f `which kill` sys-apps/procps * sys-apps/util-linux * We should probably figure out which one of these is the one we want to have. Most people will be using bash's internal `kill` command anyway, so it's not particularly urgent.
The situation was worse than you thought :) there are about a half dozen of the things it seems :-D I'll see what changes WRT to this when we switch to coreutils, and then resolve which to keep and where to keep it and all that. lost root # qpkg -f /usr/bin/kill sys-apps/sh-utils * lost root # qpkg -f /bin/kill sys-apps/procps * sys-apps/util-linux * lost root #
*** Bug 6556 has been marked as a duplicate of this bug. ***
coreutils has recently become a dependency on my system and its the third ebuild to provide /bin/kill. So now its tripiclated.
I believe we should add "touch /bin/kill" to procps ebuild in the pkg_preinst portion, and then make sure that it doesn't actually install kill, leave coreutils to install kill. This I say becaose procps' version of kill is not in the latest 2.0 version.
# etcat -b /bin/kill Searching for /bin/kill in * ... sys-apps/coreutils-5.0-r3 sys-apps/procps-3.1.9 sys-apps/util-linux-2.11z-r6 (not mentioning the obsolete *utils) ...this is a real mess... :-( Radek
*** Bug 32607 has been marked as a duplicate of this bug. ***
procps is what I'm going to force to install /bin/kill, I'm removing it from coreutils and util-linux
fixed with the recent bumps of coreutils and procps. coreutils will no longer compile su, kill, groups, hostname and uptime (where shadow and procps will provide the appropriate ones). additionally, util-linux will not compile kill either.
