[arch-dev-public] [RFC] merge /bin, /sbin, /lib into /usr/bin and /usr/lib

[Tom Gundersen]

Hi guys,


Some of us have been discussing the feasibility of merging /bin, /sbin
and /lib with their /usr counterparts. It seems that this is doable
and a few of us have been testing it locally. However, before doing
any more work on this I thought it would  make sense to make an
official proposal to find out if this is something people would be
happy with, at least in principle. If so, we could get back to a more
concrete proposal once the details have been worked out.

I assume that most people are familiar with the general idea and why
we would want to do this, but just in case I'll outline my point of
view:

 * Traditionally we have kept all our binaries and libraries in /usr.
The exception were the things needed during early boot before /usr was
mounted (assuming it was on a separate partition, if not there was
never any need for this at all).

 * We now mount /usr from the initramfs, so there is no longer any
need to keep any binaries or libraries on the rootfs.

 * Having four different locations for binaries ({/usr,}/{s,}bin}) and
two locations for libraries ({/usr,}/lib) is less KISS than having one
location for binaries /usr/bin and one for libraries /usr/lib.

 * By symlinking the old directories to /usr/{bin,lib} we keep
backwards compatibility, and also improve our compatibility with
distros that chose to put their binaries in different locations.

 * Several of the packages that have traditionally been outside of
/usr, are being maintained by people who develop on systems where
there is no longer a split. In the long term this means that more
maintenance will be shifted towards us as we have to check and fix any
assumptions that these devs might have made that don't apply to us
(unless we also do the merge).

 * Two common objections: 1) why not move everything to /: that would
mean littering the rootfs with lots of new dirs, for no gain. Having
all of the static package files in one dir (/usr) seems much cleaner
to me. 2) we should distinguish between bin and sbin: whenever people
add features to a "superuser only tool" so that it becomes useful to a
regular user, it means it should be moved from sbin to bin. However,
in practice this does not happen due to the paths being hardcoded.
Instead we just put both sbin and bin in everyone's PATH and the
distinction is essentially meaningless.

Implementation:

/lib:

For the libraries this can be done package-by-package, some have
already been done. There are also other things in /lib, I propose that
we temporarily patch udev, kmod and the few other packages to support
both /usr/lib and /lib (similarly to how systemd already works) so
things like udev rules and modprobe files can be moved over one
package at a time. Once all of this has moved, the last package to be
updated would be glibc that would move the linker and symlink /lib to
/usr/lib to maintain compat. We could then remove any transition
patches from udev++. For e this is sort of a no-brainer, with no real
risks or downsides.

/bin, /sbin:

This is a bit more tricky, and would essentially require a rebuild of
the ~90 relevant packages to move their contents to /usr/bin and move
these packages together with a new filesystem package that symlinks
/sbin and /bin to /usr/bin. I'm just giving a rough overview here, I
don't think there is any need for getting bogged down in details until
we have made our decision.

/usr/sbin:

I think there is no point in keeping this directory, and it should
eventually also be merged with /usr/bin. However, there is no need to
do this at the same time, so let's get back to this once we have some
experience from the above moves.



TL;DR: If you don't package stuff needed by early boot, this should
not matter to you one bit (fingers crossed).



Thougts?

Tom