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