On 28/11/2018 11:36, Rick Moen wrote:
> 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).

Prior to wheezy, this was considered vital and was explicitly required
and enforced. From wheezy onward, this requirement was deliberately and
intentionally dropped.

If you want to backup, restore, or repair your system, you can still do
so. But you have to do so with /usr present either as part of the
rootfs or mounted as a separate filesystem.

This isn't a bug, or even a feature. It's a deliberate design decision
which affects the functioning of the system as a whole. I understand
your concerns, and I even sympathise with them, but the decision to do
this was taken over six years ago after extensive discussion, and it's
been implemented and released six and four years ago, respectively.

> 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.

I tried to explain the rationale for the decision in a reasonable amount
of detail, along with some of the competing concerns which affected it.
I'm not trying to convince you that your points are not important for
your needs or that they are irrelevant. But the decision was already
made and implemented for quite a long time now. I'm simply trying to
explain why things are the way they are today.

I'm also not trying to say that I'm fully happy with the decision or its
consequences. Like many decisions, it arose as a imperfect compromise
which considered many different competing use cases and requirements,
and tried to pick the path which provided the most benefit for the least
harm. We did the best we could. And if we had to do it over again, I
don't think much would be materially different. We did a pretty good
job given the constraints. Limitations on the use of a fully separate
mountable /usr were the price we had to pay for a whole host of benefits
which were considered to be worth that cost.

>> 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.

Debian did try this choice, for most of the 2000s. We repeatedly moved
libraries and tools from /usr to the rootfs which were needed for early
boot. But the number of libraries and tools which *might* be needed was
ever increasing. The problem was not scalable or tractable for a
general-purpose distribution.

We only switched to the current solution when it became clear that this
approach wasn't working and that there were a number of problems which
couldn't be resolved by this approach. A lot of effort was put into
trying to make this approach work.

The current solution *is* scalable and tractable for pretty much any
esoteric boot requirements you might have. Because it doesn't depend
upon having a pre-approved shortlist of early-boot packages treated
specially, it works for all packages.

> (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.)

This is good advice. But for the problem in question, it's not a bug
which can be worked around this way, it's a fairly fundamental design
choice which just isn't fixable with small patches here and there. It's
systemic.


Regards,
Roger