On 08/14/2015 10:24 AM, Lennart Poettering wrote: > On Mon, 10.08.15 11:50, Josh Stone (jistone@xxxxxxxxxx) wrote: > >> On 08/10/2015 11:12 AM, Orion Poplawski wrote: >>> iproute has /usr/sbin/ss >>> stripesnoop has /usr/bin/ss >>> >>> This causes problems: https://bugzilla.redhat.com/show_bug.cgi?id=1249328 >>> >>> It seems like we should have a policy prohibiting different programs with the >>> same command names being in /usr/bin and /usr/sbin. Thoughts? >> >> Do emphasize *different* programs or packages, as there are legitimate >> self-contained cases -- /usr/bin/mock vs. /usr/sbin/mock for instance. > > I would also say that this is hardly "legitimate", it's just wrong to > do this, and we should disallow this in Fedora. > > Given that sbin is in $PATH for unprivileged users too the seperation > is really pointless, since it's now only the $PATH order which makes > this not explode. > > Having the same binary doing different things in two places is just > confusing, opaque to the admin and also not compatible with other > distros (such as Arch for example, where sbin is just a compat symlink > to bin, or distros where the $PATH order differs). In fact, I am > pretty sure on Fedora we should get rid of sbin too, and turn it into > a proper symlink to bin. That way we could get rid of all the symlinks > from /sbin binaries to their /bin binaries for compat reasons and just > make everything compatible with everything. > > Yes, mock should be fixed to not install two different things to the > two paths. It's really ugly from mock... Well, mock is just using consolehelper, so I guess you should set your sights on that. Another big example with consolehelper is authconfig. I also see /usr/bin/lshw-gui as a wrapper on pkexec /usr/sbin/gtk-lshw, whereas /usr/sbin/lshw-gui is a direct symlink. The rest of the dupes on my system appear to be just unifying symlinks, in one direction or the other, supporting the idea of a bin+sbin merge. There's still plenty that's unique to sbin though. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
