Steve Litt wrote on 16.11.18 18:17:
> On Fri, 16 Nov 2018 11:34:05 +0100
> Irrwahn <irrwahn@???> wrote:
>
>> I cast my vote in favor of making merged /usr the default.
[...]
>> Split /usr is an abomination that should have been put to rest long
>> ago, only to be referred to as quirky anecdote in some obscure
>> footnote. Merging /usr back is a small step on the long way to
>> restore the FSH to what it was meant to be.
>
> Wait a minute. You and I are talking about two different things, so
> perhaps I should ask what the "/usr merge" really is.
>
> Urban, you seem to be against having both a /usr/bin and a /bin.
> Personally, I don't care about that.

Steve,

since we're having this discussion in the light of Debian making (or at
least planning to make) merged /usr the default selection in the next
stable version installer, I guess we should consult the FAQ that comes
with the `usrmerge´ package in Debian, c.f.:

https://salsa.debian.org/md/usrmerge/raw/master/debian/README.Debian

Excerpt:

| * What is the purpose of this package?
| The usrmerge package will convert the system it is installed on to the
| everything-in-usr directories scheme, i.e. the /{bin,sbin,lib}/ directories
| become symbolic links to /usr/{bin,sbin,lib}/.
| [...]

| * Will usrmerge also merge /usr/bin/ and /usr/sbin/?
| No.

| * Does this require systemd?
| No.

| * Does this really not require systemd?
| Yes, I promise.

| * Does this require an initramfs?
| Only if /usr is on a standalone file system.

So, bin and sbin will stay separate, but /bin, /sbin and /lib will get
merged into, and replaced by symlinks to, their counterparts in /usr.

> What *I'm* talking about is I want to continue having /sbin separate
> from /bin and /usr/bin, because the /sbin varieties holds statically
> compiled programs guaranteed to work at the earliest of boots, and in
> the case of /sbin, guaranteed to be available as soon as / is mounted.

When was the last time you checked what actually resides in /sbin?
It may come as a surprise, but statically linked programs it's not.
Picking some random example, let's have a quick look at `getty´:
  $ ldd /sbin/getty 
    linux-vdso.so.1 (0x00007fff16f88000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3afe0ec000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3afdee8000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3afdccb000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f3afe8a3000)

It's less surprising when taking into consideration that with all but
the most trivial of programs it's basically impossible to achieve
statical linkage with glibc, and it has been like that for years now.
If you really want statically linked executables you need to have a
look beyond glibc, e.g. at musl-libc. (Which is what I did in my past
experiments to build a small non-GNU Linux system around toybox and
clang/musl-libc.)

>
> I want there to always exist a /sbin, where static executables become
> available the microsecond / is mounted. /sbin should be there only for
> statically compiled executables needed for early boot. As long as /sbin
> contains everything needed to boot in all but the craziest situations,
> I don't care what happens to /usr/sbin.
>
> But the minute somebody combines /sbin with /usr/bin or /usr/sbin,
> everything I said in my previous post becomes true.

Only if you insist on mounting /usr separately from /. If your hardware
is no older than ~40 years there should exist no compelling /technical/
reason to do so. The only arguments pro separate /usr I came across so
far were all based on either ill advised practice to abuse the artificial
/usr split (e.g. shared /usr via NFS), or some variation of "but I always
did it that way".

If your mass storage devices are too tiny to allow for a single partition
to hold the combined content of /{bin,sbin,lib} and /usr, something else
is fundamentally amiss. Even on my kitchen sink desktop PC the entire /
hierarchy *including everything except /home*, amounts to a meager 10GB.
(1.4 GB of which is /var, BTW, for which there actually exist sound
technical reasons to have it on a separate partition, as is the case for
/home.)

Regards,
Urban

--
Sapere aude!