On Wed, Nov 21, 2018 at 12:17:21PM +0000, Roger Leigh wrote: > 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.
hendrik@midwinter:~$ ls /usr bin games include lib local lost+found sbin share src hendrik@midwinter:~$ better to symlink /usr/bin to /bin, /usr/games to /games, and so forth. Otherwise recursive file scans can easily end up looping through /, /usr, /usr/usr, /usr/usr/usr, and so forth. -- hendrik ... ... > > 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. Better for the /usr to be corrupt than for / to become corrupt. With merely a corrupt /usr, it's still possible to use system recovery tools in / to recover the system. Unless, of course they've all been moved to /usr with symlinks. -- hendrik _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng