Quoting Didier Kryn (kryn@???):

> IIUC, your argument boils down to "depending on /usr for early boot is
> a *bug*", while Roger told us why it has become a *feature* (~:

My view, which I expressed in detail prior to Roger joining the thread,
is that it's vital to the most vital function of the root filesystem's
maintenance software directories (/sbin, /bin, /lib, /lib64) that their
binaries function _even_ if /usr is not (or at the moment cannot be)
mounted -- because the most vital function of those subtrees is backup,
restore, repair, maintenance (functions that might be required to
recover/fix /usr).

I addressed the main part of Roger's initial post upthread, and don't
care to revisit that discussion, except to mention that he dismissed the
use-case cited above, which is the traditional Unix use-case, in wording
that didn't address the substance of those concerns.

> It would certainly be possible to move all applications and dynamic
> libraries needed for early boot from the /usr tree to /bin, /sbin and
> /lib, but Debian has made a different choice.

I'm not 100% sure what you mean by 'early boot' in context of recent
discussion about separate /usr. What I'm talking about is maintenance,
approximating as mentioned backup, restore, repair, maintenance. It is
an integral part of Rick Moen system local policy that those functions
must work whether or not /usr is yet present (because they may be called
upon to rebuild or recover /usr). If indeed Debian policy differs, to
the extent that it differs, then that still doesn't bother me a great
deal, since Rick Moen local policy is applied as required to overrule
Debian policy. Problem solved. ;->

(This is why I tend not to waste time hyperventilating about dumb distro
policy decisions: Submit a bug. If it's rejected or never acted on,
just make a local configuration that works around the stupid distro
action, and move on to more rewarding parts of life. If moved to
public-spiritedness, also publish one's fix a part of a third-party
package repo, pro bono public, to help others benefit from your work
without needing to replicate ito.)

> In the case of NFS, I agree that the only thing to do would be to move
> the dynamic library to /lib. Instead, it seems /lib has become a holly
> directory where only the libc and the dynamic linker are allowed to
> live.

That would fix the ldd depency of mount.nfs on /usr/lib contents, yes.