On Sun, Aug 16, 2015 at 7:25 PM, Reindl Harald <h.reindl(a)thelounge.net>
wrote:
Am 17.08.2015 um 01:22 schrieb Nico Kadel-Garcia:
> On Sun, Aug 16, 2015 at 6:24 PM, Nico Kadel-Garcia <nkadel(a)gmail.com>
> wrote:
>
>> On Sun, Aug 16, 2015 at 2:31 PM, Reindl Harald <h.reindl(a)thelounge.net>
>> wrote:
>>
>>>
>>> Am 16.08.2015 um 18:57 schrieb Nico Kadel-Garcia:
>>>
>>>>
>>>> It's a basic violation of the ordinary segregation between
"/bin" as
>>>> ordinary user tools" and "/sbin" as sysadmin tools to
start mixing
>>>> them, and much more confusing to have the same program name in both.
>>>> And it's frankly easy to avoid. "mock", for example, should
rename
>>>> "/.sbin/mock" to something else to avoid command line
confusion
>>>>
>>>
>>> nonsense
>>>
>>> ./sbin/ is nowehre in the FHS
>>> ./sbin/ is not below/usr
>>> ./sbin is not protected ReadOnlyDirectories=/usr
>>>
>>> /usr/lib/appname and /usr/libexec exists
>>>
>>
>> /sbin isn't a separate filesystem, it is a subdirectory of "/",
and
>> it's explicitly mentioned at
>>
http://www.pathname.com/fhs/2.2/fhs-3.14.html as requiring copies or
>> symlinks to certain specific, long-stable program names. Let me quote
>> that document:
>>
>
> Ahhh, I am sorry, I may have contributed to the confusion by mistyping
> "/sbin" as ""/.sbin". I'm on a new email interface, and
am having some
> difficulty with "overwriting" as opposed to my preferred default
> "insertion" for editing. But that was my own fault
>
the same nonsense
/sbin is the same as /usr/sbin for a long time now
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
http://fedoraproject.org/code-of-conduct
Quoting in FHS 3.0
<
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html> (which is
really the one we should be looking at):
*The following commands, or symbolic links to commands*... (Sect 3.16.2)
[...]
*The following files, or symbolic links to files*... (Sect 3.16.3)
(From FHS chapter 3.16 "/sbin: System binaries"
<
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s16.html>)
Thus, it sounds like FHS is okay with the idea of */sbin* being symlinked
to some other directory. Ultimately, FHS doesn't appear to mandate that the
folder and its contents must physically exist there, only that they are
present to enable "*booting, restoring, recovering, and/or repairing the
system*" (Sect 3.16.1).
The split between */sbin* and */bin* was largely for providing a logical
division of core administrative functions and the rest of the stuff
installed. Frankly, I don't see how that matters so much anymore. FHS
doesn't even recommend walling off access to */sbin*, either.
--
真実はいつも一つ!/ Always, there's only one truth!