Suppose a package has a boot-time, size-optimized, limited binary in /bin/runk and a user-optimized, feature-complete binary that requires the entire system to be up in /usr/bin/runk. When /bin and /usr/bin link to the same directory, the package manager will extract these files and run into a problem.
Things become even more complicated when these tools are split into different packages (say runk-boot and runk-user). Tracking which file comes from which package can become near impossible.
Of course this can be resolved relatively easily; make the package manager link-aware by handling the merged-bin setup as a special case and warn or error when files conflict. People don't seem to want to do that for various reasons, some good, some based in opinion only. It's a mess.
This can also be resolved externally by controlling the repos and not fucking it up. Package conflicts are already a thing, Debian already has all the infra, you've always been able to cause the "theoretical" "breakage". Frankly, it's already a non-problem.
Suppose a package has a boot-time, size-optimized, limited binary in /bin/runk and a user-optimized, feature-complete binary that requires the entire system to be up in /usr/bin/runk. When /bin and /usr/bin link to the same directory, the package manager will extract these files and run into a problem.
Things become even more complicated when these tools are split into different packages (say runk-boot and runk-user). Tracking which file comes from which package can become near impossible.
Of course this can be resolved relatively easily; make the package manager link-aware by handling the merged-bin setup as a special case and warn or error when files conflict. People don't seem to want to do that for various reasons, some good, some based in opinion only. It's a mess.