Hi cacin, I see that you are working on merging /bin and /sbin, for instance via brltty bug #1064785. Again Fedora is pioneering this matter and their documentation is at https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin.
Please allow me to push back on this one as well by raising a few concerns. Fundamentally, turning sbin into a symlink pointing to bin is causing aliasing problems that we currently have a hard time fixing up for the /usr-merge. If doing this, I think we need a different technical approach. Doing the aliasing mess again does not sound like a valid option to me. In the /usr-merge discussion, alternatives have been proposed. For instance, there as a proposal that would manage a symlink farm via dpkg triggers until the aliased directory would become unpopulated (by packages) and then turn the farm into a symlink. If doing the symlink first, I think we need changes to dpkg before creating such a symlink to make this approach viable. Apart from the implementation side, this is a more user visible change. As you complete programs in a user shell, more programs become available. This can be good, but it can also be seen as a pollution of your shell completion. I note that Fedora seems to have added /sbin to the user $PATH by default, which is not what Debian has done. I do not think we have consensus on this and would raise an objection of my own. That said, I appreciate your work on analyzing the situation as it also uncovers tangential problems e.g. where different packages put programs with different functionality into bin and sbin. It is up to interpretation of Debian policy whether that should be considered an RC-bug (10.1 "same filenames"). In general, I think that having each program name on either bin or sbin but not both is a desirable property and it should be easier to gain consensus on this. As we've seen with arcstat (zfs vs nordugrid), doing so will take a long time. Where we expect downstreams to not have hardcoded paths to programs /usr/sbin/foo, dropping a symlink from sbin/foo -> ../bin/foo probably is reasonable, but needs to be reviewed case by case. As we see, this is not a single change to be working on, but multiple related and interdependent topics. Disentangling these matters and making the intention clear is key to moving this forward. Regardless of whether we (as a project) want sbin merged into bin or not, reducing conflicts (different functionality but same name) between sbin and bin is a hard prerequisite, difficult to achieve and probably and agreeable goal. Helmut
