On merging bin and sbin

[Helmut Grohne <helmut@subdivi.de>]

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