Hi folks,
I've been following the discussion with interest. It's certainly not a
new discussion, since I remember debating it a good few years back, but
there are still the same opinions and thoughts on the topic that I
remember from back then.
Some general points to consider:
1) A separate /usr serves no practical purpose on a Debian/Devuan system
Historically, /usr was separately mountable, shareable over NFS.
With a package manager like dpkg, / and /usr are an integrated, managed
whole. Sharing over NFS is not practical since the managed files span
both parts, and you can't split the package database between separate
systems. Modern disk sizes make partitioning a separate /usr
unnecessary and undesirable. (Both are of course /possible/, but there
is precious little to gain by doing so.)
Other systems, like the BSDs, have the effective split between base
(/) and ports (/usr/local). / and /usr are still effectively a managed
whole containing the "base system".
With those points considered, merging / and /usr would make sense.
Though equally, keeping the separation doesn't hurt *if they are on the
same filesystem*. If they are to be merged, then there are two
possibilities: moving /usr to / or the contents of /* to /usr.
The point about /usr being a good place for "static" content is a
reasonable one. But for better or worse, / is "the system". It's still
part of the managed whole, and hiving off a static /usr rather than
hiving off the variable changing content isn't really doing more than
adding extra unnecessary complexity.
2) Moving the content to /usr doesn't preclude moving it to / later
RedHat/systemd have decided to move everything to /usr, and Debian
have decided to copy this as they have for most systemd-dictated
changes. I'd prefer it to be the other way around; it's cleaner and
it's what we would choose given a clean slate. However, when multiple
filesystems are in use, /usr is often larger and this is potentially the
safer move *for upgrades*.
dpkg permits any directory in the filesystem hierarchy to be
replaced by a symbolic link. If the contents of /bin, /lib etc. are
moved to /usr/bin, /usr/lib etc., they can be replaced by symlinks so
that /bin/sh and /lib/ld.so and other fixed paths continue to work
correctly.
Conversely, /usr can be symlinked to /. This permits /usr/bin/perl
to continue to work even if the interpreter is in /bin.
However, dpkg must compare canonical paths rather than the
package-provided paths, to detect file conflicts between packages using
/ vs /usr paths. I'm not sure if it does this already or not.
There are two parts to the unification:
a) Cleaning up all packages such that there are no conflicts
between the contents of /bin and /usr/bin
b) Moving the files and creating the symlinks
The important point to note is that once the cleanup is done, the
symlinks can be made to support either scenario. dpkg doesn't care, so
long as there are no duplicate files in either location. You could do a
migration to /usr on upgrade (for safety) and make /usr a symlink to /
on fresh installs. The important part is (a). (b) is policy, which can
be changed at will as distribution defaults or local choice.
3) Upgrade incompatibility
The point made about the kmod developers switching to /usr/lib makes
no sense. If the migration is done correctly, it should be *seamless*.
Because /lib should point to /usr/lib, any existing users of /lib should
retain using that path for compatibility purposes. Indefinitely, if
they cared about doing it properly. No user of /lib should transition
to /usr/lib, just like no user of /var/run should have transitioned to
/run. The important part of being compatible across filesystem layout
changes is not breaking *anything* before or after the unification.
4) None of it actually matters
The whole discussion is based on the premise that they are separate.
In practice, the vast majority of us have them on the same filesystem,
given that there is no practical purpose to the separation as in (1) above.
If you are using a container-based system like Docker, or a virtual
machine image, or a live image, they will be a single filesystem. If
you're doing a standard installation, they will be a single filesystem.
Also, if you're using a modern filesystem like ZFS, on Linux:
% zfs list -r rpool
NAME USED AVAIL REFER MOUNTPOINT
rpool 51.0G 56.5G 96K none
rpool/ROOT 14.6G 56.5G 96K none
rpool/ROOT/default 14.6G 56.5G 12.0G /
rpool/home 3.18M 56.5G 96K none
rpool/home/root 3.08M 56.5G 3.08M /root
rpool/opt 16.3G 56.5G 9.63G /opt
rpool/opt/clion 1.19G 56.5G 616M /opt/clion
rpool/opt/qt 4.34G 56.5G 4.34G /opt/qt
rpool/swap 14.3G 62.6G 5.82G -
rpool/var 5.66G 56.5G 96K none
rpool/var/cache 5.28G 56.5G 5.14G /var/cache
rpool/var/log 385M 56.5G 381M /var/log
rpool/var/spool 7.97M 56.5G 7.85M /var/spool
rpool/var/tmp 344K 56.5G 184K /var/tmp
On FreeBSD:
% zfs list -r system
NAME USED AVAIL REFER MOUNTPOINT
system 16.0G 22.5G 144K none
system/ROOT 11.9G 22.5G 144K none
system/ROOT/default 11.9G 22.5G 11.9G /
system/tmp 276K 22.5G 276K none
system/usr 364K 22.5G 144K /usr
system/usr/home 220K 22.5G 220K /usr/home
system/var 4.05G 22.5G 3.94G /var
system/var/crash 144K 22.5G 144K /var/crash
system/var/log 6.37M 22.5G 2.00M /var/log
system/var/mail 2.45M 22.5G 1.95M /var/mail
system/var/tmp 152K 22.5G 152K /var/tmp
For the latter it is using a separate /usr, but since it's all in
the same pool and can be recursively snapshot, the separate filesystems
can be treated as a managed collection. It's still pointless though.
Like a lot of systemd-driven changes, unifying these filesystems is
technically possible, slightly desirable, but at a huge practical cost.
The main costs are the severe risks taken to migrate essential system
files and rearrange the root filesystem during an upgrade. Given that
from the user's and sysadmin's point of view, the system behaves the
same both before and after the upgrade, they are being required to
undertake a large risk for *almost zero* practical benefit. Personally,
I would argue this should only be done for fresh installations. I don't
think the potential for near-irreparable damage to running systems is
acceptable. Depending upon the configuration, there's a risk of the
system no longer being bootable, of the system being in a corrupt state
if the migration fails due to the /usr filesystem not having enough
space to migrate the files, or dpkg not being able to revert or complete
the operation if interrupted.
Lastly, regarding the comments about Devuan "disenfranchising" itself
from Debian to not be "in the back seat". I take the point, but the
practical reality is that Debian is so huge not even a company with many
dozens of employees like Canonical could manage that feat. It's simply
impractical. If Devuan continues as a derivative by maintaining a
modified set of core packages to meet specific goals, it would seem that
it's meeting it's core objectives, and that's no bad thing. It's
realistic, and manageable.
Best wishes all,
Roger
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
