The problem is that the multicall executable is installed into /usr/bin, despite the fact that half of the programs it runs are in /bin. This creates an undue burdon, especially when attempting to rescue a broken system, because if /usr fails to mount for some reason then the entire coreutils suite becomes unavailable! This is unacceptable. The USE=multicall feature is primarily advertised as a way to save disk space. However, logic would follow that it would have many other performance benefits on a modern system such as reduced memory required by page cache, reduced mmaped memory, reduced CPU cache misses, etc. -- especially when running shell scripts that call many such executables in a short period of time. Therefore, I would consider this feature to have value beyond storage- and memory-constrained systems.
this is why we install busybox. that is the system rescue shell, not packages like coreutils.
(In reply to SpanKY from comment #1) > this is why we install busybox. that is the system rescue shell, not > packages like coreutils. Yes, indeed I have busybox on my system and that's how I recovered, but that does not invalidate the problem. Why should we have to rely on busybox when coreutils should have functioned? If it's installed in /{,s}bin, it should work w/o /usr.
(In reply to Daniel Santos from comment #2) i haven't closed the bug because i plan on moving `coreutils`. but i think you missed my point: the Gentoo rescue policy is to use busybox. we do not rely on other packages such as coreutils.
