Same comand names in /usr/bin and /usr/sbin

Josh Stone jistone at redhat.com
Fri Aug 14 21:17:04 UTC 2015


On 08/14/2015 10:24 AM, Lennart Poettering wrote:
> On Mon, 10.08.15 11:50, Josh Stone (jistone at redhat.com) 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.


More information about the devel mailing list