On Sun, Aug 16, 2015 at 7:25 PM, Reindl Harald <h.reindl@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@gmail.com> wrote:
On Sun, Aug 16, 2015 at 2:31 PM, Reindl Harald <h.reindl@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@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 (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")

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!