Bug#978636: move to merged-usr-only?
On Mon, 25 Jan 2021 at 11:46:35 -0700, Sean Whitton wrote:
> > The Technical Committee resolves that Debian 'bookworm' should support
> > only the merged-usr root filesystem layout, dropping support for the
> > non-merged-usr layout.
Should we be more specific than this in what we vote on, to avoid
later having to adjudicate between developers who say that a particular
implementation is or isn't merged-usr?
Some developers seem to be using "merged /usr" to refer to multiple
concrete layouts:
1. an arrangement where all regular files that have traditionally been
in /bin, /sbin, /lib and /lib64 are physically located in /usr,
with symlinks /bin -> usr/bin, /sbin -> usr/sbin, /lib -> usr/lib,
/lib64 -> usr/lib64
(this is what usrmerge, debootstrap --merged-usr and Fedora do; dpkg
maintainer Guillem Jover refers to this as "merged /usr via aliased
directories" which seems like a good unambiguous term)
2. an arrangement where all regular files that have traditionally been
in /bin, /sbin, /lib and /lib64 are physically located in /usr,
with /bin etc. becoming "symlink farms" containing symlinks like
/bin/sh -> /usr/bin/sh, /lib/ld-linux.so.2 -> /usr/lib/ld-linux.so.2
and so on
2a. in one version of this, only those files that traditionally
existed in the rootfs have symlinks, so that /bin/sh -> /usr/bin/sh
exists but /bin/perl -> /usr/bin/perl does not
2b. in another version of this, every file in /usr/bin, /usr/sbin,
/usr/lib is represented in the symlink farm, so that
/bin/perl -> /usr/bin/perl exists
I think we should choose wording to vote on such that if we vote yes,
it is clear which of these layouts are consistent with that resolution,
and which are not.
Guillem considers layout 1 to be broken and a mess. I don't agree,
but I'm not a dpkg maintainer. We should be aware that mandating this
implementation is likely to require some overruling.
I don't consider 2a to be merged /usr: it only does half the job of making
the directories in the rootfs equivalent to the directories in /usr.
For example, we would be able to run (for example) /usr/bin/sh scripts
developed on distros that don't distinguish, but not /bin/perl scripts.
However, it does do half the job, and I think Guillem might be considering
2a to be an implementation of the general concept of merged /usr?
I'm not sure whether *I* consider 2b to be merged /usr or not. It makes
the directories on the rootfs exactly equivalent to those in /usr, but
retains a lot of complexity. I would personally be willing to tolerate
that as a stepping-stone to reach layout 1, if the people who do the
work consider it to be less bad than doing the equivalent of usrmerge,
but I don't like it as a post-bullseye end goal in its own right.
If we're voting for layout 1 / status quo / FD, then that could be worded as:
The Technical Committee resolves that Debian 'bookworm' should support
only the "merged-usr via aliased directories" root filesystem layout
in which /bin, /sbin and /lib are symbolic links to the corresponding
directories in /usr, dropping support for the non-merged-usr layout.
Or if we're saying "either 1 or 2b":
The Technical Committee resolves that Debian 'bookworm' should support
only a merged-usr root filesystem layout in which /bin, /sbin and
/lib are either symbolic links to the corresponding files in /usr,
or directories containing such symbolic links, with every file
/usr/bin/foo also available via the path /bin/foo and so on.
Or if we're saying "either 1 or 2a or 2b":
The Technical Committee resolves that Debian 'bookworm' should support
only a merged-usr root filesystem layout in which /bin, /sbin and
/lib are either symbolic links to the corresponding files in /usr,
or directories containing such symbolic links.
(I'm assuming that nobody will try to argue that /lib64, /libx32 and other
libQUAL directories should be treated differently from /lib, even if I
don't explicitly enumerate them.)
Sorry to derail this but I think we should be clear about what we're
resolving.
I think this is consistent with not recommending any particular
implementation of the migration path, which I'm taking to mean we don't
mind how existing unmerged installations reach the desired state - e.g.
if we recommend layout 1, you could get there by installing usrmerge.deb,
or via a special-case in dpkg, or any other mechanism that arrives at
layout 1.
smcv
Reply to: