On 29/11/2018 12:57, karl@??? wrote:
> Roger:
> ...
>> Note that to return to the pre-merge policies would be an exercise in
>> futility. It was already an exercise in futility back in 2011 because
>> the number of libraries which /could/ be moved to /lib is an unbounded
>> set. There's always another tool which /might/ be required, which pulls
>> in yet more libraries, and their dependencies, and the dependencies of
>> their dependencies and so on. It's a Sisyphean task.
>
> It wouldn't be for a subset of booting setups. It is perfectly possible
> for a certain set. If I make a make a kernel package, I can certainly
> say that that this package supports direct boot to disk without initrd
> and with a separate /usr, with the constraint that it don't support
> e.g. lvm and other setups.
>
> Why not agree on a certain set of programs/libs that should be in /bin,
> /sbin, and /lib, just to not break my and others packages. That set
> don't need to cover all booting possibilities.

This is what we used to (try) to do, but we failed at it. Even when the
policy was to not allow any library dependencies in /usr for binaries in
/ there were many dozens that crept in unnoticed. The fact that they
crept in is also part of the problem; mounting /usr was sufficiently
niche that it didn't get enough testing to pick up these problems and
resolve them before they caused trouble. That alone was a warning sign
that this option wasn't well supported and was subject to breakage as a
result, and is also a factor in its demise.

The problem is agreeing on what is essential for booting, and what is
not. There's so much variety in differing requirements that satisfying
everyone is impossible. For example, ext[234], md and lvm2 might be a
common requirement, maybe xfs and btrfs-tools as well. How about ZFS?
Ceph? GlusterFS? Or proprietary third-party filesystems like IBM GPFS.
LDAP. Encryption. Networking. CA Certificates. SSL/TLS. There's
always "just one more" requirement, which critically breaks someone's
system if it's not specially catered for. This is why the problem is
unbounded and this situation was untenable. It made a separate /usr
completely unusable for a good number of perfectly legitimate setups,
many of which were hard requirements for working in large corporate or
academic IT environments, where it had to inter-operate well with the
existing infrastructure. The fact that Debian was hideously broken by
default for all these use cases had been an embarrassment for a number
of years which we needed to solve.

We could certainly pick an essential subset of tools and filesystems,
and state that this combination is allowed for mounting /usr. But this
is basically drawing a line in the sand and saying that outside those
essential packages, everything else is a second-class citizen which
isn't properly supported. One of the points which has been made
multiple times is the need for freedom for the admin to configure their
systems as they like. It's obviously important. But by drawing this
line we are saying that you /can't/ have the freedom to use anything
outside this essential set because it will break. Forget about
experimenting with new and interesting filesystems. And forget about
integrating with the infrastructure required by your company.

And lest anyone forget history, it was once impossible to use md or lvm
(or btrfs etc.) for booting, before all that special-casing and
bootloader support was in place. I was one of the first people to try
all that out and identify the problems when it was brand spanking new.
The same restrictions apply to any new technologies which come along in
the future. We don't want to deliberately limit future possibilities.

Those factors had to be weighed against the need to mount a /usr without
an initramfs. The number of people doing this was a niche subset of a
already very small subset. We support booting without an initramfs. We
support booting with a separate /usr. But not both together. There are
limits to what is possible and reasonable to support, and that use case
was judged to be so tiny that the other use cases were of greater benefit.

No matter how you slice it, restrictions were going to be placed upon
the use of a separate /usr for one subset of users or another. The
status quo was that it worked without an initramfs, but was broken for a
large number of other scenarios. We stopped it working without an
initramfs but made it work for **all** of the other scenarios. So in
terms of allowing a separate /usr, we actually /increased/ its
flexibility and utility at the expense of this one use case. I tried my
hardest to avoid any breakage at all, but I couldn't figure out a
supportable way to do this. If anyone can figure out a solution, then
I'd be very happy. However, given that the solution to the problem is
to simply use an initramfs, that's the official solution here. Keep a
separate /usr, but use the initramfs as intended. Problem solved.

It does suck if you're in the tiny subset that lost out here. But,
that's life, and we provided perfectly viable supported and tested
workarounds. If people want to deliberately avoid the officially
supported boot methods, that's really not the distribution's problem!
We had to consider all the options and make the call which would benefit
the most people according to the group consensus. If we'd have gone the
other way we would have screwed over a much larger number of people, and
made Debian unusable in a number of significant usage scenarios.


Regards,
Roger