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