The Case for the /usr Merge

Tolkem · 2021-08-24 16:35

As some of you might know, as read here https://www.debian.org/releases/bullsey … components

Debian bullseye will be the last Debian release that supports the non-merged-usr layout; for systems with a legacy layout that have been upgraded without a reinstall, the usrmerge package exists to do the conversion if desired.

So, I've been wondering whether Q4OS Gemini will use usrmerge and implement this, or if it will continue with the traditional approach; filesystem layout with /bin, /sbin, and /lib directories separate from their equivalents under /usr. And according to this https://www.freedesktop.org/wiki/Softwa … eUsrMerge/ the change is for the better since

The historical justification for a /bin, /sbin and /lib separate from /usr no longer applies today. (More on the historical justification for the split, by Rob Landley) They were split off to have selected tools on a faster hard disk (which was small, because it was more expensive) and to contain all the tools necessary to mount the slower /usr partition. Today, a separate /usr partition already must be mounted by the initramfs during early boot, thus making the justification for a split-off moot. In addition a lot of tools in /bin and /sbin in the status quo already lost the ability to run without a pre-mounted /usr. There is no valid reason anymore to have the operating system spread over multiple hierarchies, it lost its purpose.

and

You are wondering why merging /bin, /sbin, /lib, /lib64 into their respective counterparts in /usr makes sense, and why distributions are pushing for it? You are wondering whether your own distribution should adopt the same change? Here are a few answers to these questions, with an emphasis on a compatibility point of view:
Compatibility: The Gist of It
Improved compatibility with other Unixes/Linuxes in behavior: After the /usr merge all binaries become available in both /bin and /usr/bin, resp. both /sbin and /usr/sbin (simply because /bin becomes a symlink to /usr/bin, resp. /sbin to /usr/sbin). That means scripts/programs written for other Unixes or other Linuxes and ported to your distribution will no longer need fixing for the file system paths of the binaries called, which is otherwise a major source of frustration. /usr/bin and /bin (resp. /usr/sbin and /sbin) become entirely equivalent.
Improved compatibility with other Unixes (in particular Solaris) in appearance: The primary commercial Unix implementation is nowadays Oracle Solaris. Solaris has already completed the same /usr merge in Solaris 11. By making the same change in Linux we minimize the difference towards the primary Unix implementation, thus easing portability from Solaris.
Improved compatibility with GNU build systems: The biggest part of Linux software is built with GNU autoconf/automake (i.e. GNU autotools), which are unaware of the Linux-specific /usr split. Maintaining the /usr split requires non-trivial project-specific handling in the upstream build system, and in your distribution's packages. With the /usr merge, this work becomes unnecessary and porting packages to Linux becomes simpler.
Improved compatibility with current upstream development: In order to minimize the delta from your Linux distribution to upstream development the /usr merge is key.

and

One major benefit of the /usr merge is the reduction of complexity of our system: the new file system hierarchy becomes much simpler, and the separation between (read-only, potentially even immutable) vendor-supplied OS resources and users resources becomes much cleaner. As a result of the reduced complexity of the hierarchy, packaging becomes much simpler too, since the problems of handling the split in the .spec files go away.
The merged directory /usr, containing almost the entire vendor-supplied operating system resources, offers us a number of new features regarding OS snapshotting and options for enterprise environments for network sharing or running multiple guests on one host. Static vendor-supplied OS resources are monopolized at a single location, that can be made read-only easily, either for the whole system or individually for each service. Most of this is much harder to accomplish, or even impossible, with the current arbitrary split of tools across multiple directories.
With all vendor-supplied OS resources in a single directory /usr they may be shared atomically, snapshots of them become atomic, and the file system may be made read-only as a single unit.

Just curious.

tlmiller76 · 2021-08-24 17:05

If q4os Gemini starts with a "base" Debian iso before updating it, then Gemini will install with everything already merged. Bullseye by default will have new installs already merged. At some point in Busters lifetime IT even defaulted to the merged setup as the default (not sure when though, it was definitely BEFORE 10.7 though). So most likely (and I don't have my install in front of me to check), I'd bet q4os Gemini at least already uses a merged /usr structure, and wouldn't be OVERLY surprised if Centaurus does already as well.

Tolkem · 2021-08-24 18:33

tlmiller76 wrote:

If q4os Gemini starts with a "base" Debian iso before updating it, then Gemini will install with everything already merged. Bullseye by default will have new installs already merged. At some point in Busters lifetime IT even defaulted to the merged setup as the default (not sure when though, it was definitely BEFORE 10.7 though). So most likely (and I don't have my install in front of me to check), I'd bet q4os Gemini at least already uses a merged /usr structure, and wouldn't be OVERLY surprised if Centaurus does already as well.

Ah, seems you're right, just checked, and I can see /bin, /sbin, and /lib in /usr.

tlmiller76 · 2021-08-24 20:31

They should have all already been there, but do you see in / that those directories are symlinks to the /usr/<> directories?

root@azphxlxittimmil:~# ls -lash / | grep -E "lib|bin|sbin"
   0 lrwxrwxrwx   1 root root    7 Aug 24 12:27 bin -> usr/bin
   0 lrwxrwxrwx   1 root root    7 Aug 24 12:27 lib -> usr/lib
   0 lrwxrwxrwx   1 root root    9 Aug 24 12:27 lib32 -> usr/lib32
   0 lrwxrwxrwx   1 root root    9 Aug 24 12:27 lib64 -> usr/lib64
   0 lrwxrwxrwx   1 root root   10 Aug 24 12:27 libx32 -> usr/libx32
   0 lrwxrwxrwx   1 root root    8 Aug 24 12:27 sbin -> usr/sbin

Tolkem · 2021-08-24 21:42

tlmiller76 wrote:

They should have all already been there, but do you see in / that those directories are symlinks to the /usr/<> directories?

root@azphxlxittimmil:~# ls -lash / | grep -E "lib|bin|sbin"
   0 lrwxrwxrwx   1 root root    7 Aug 24 12:27 bin -> usr/bin
   0 lrwxrwxrwx   1 root root    7 Aug 24 12:27 lib -> usr/lib
   0 lrwxrwxrwx   1 root root    9 Aug 24 12:27 lib32 -> usr/lib32
   0 lrwxrwxrwx   1 root root    9 Aug 24 12:27 lib64 -> usr/lib64
   0 lrwxrwxrwx   1 root root   10 Aug 24 12:27 libx32 -> usr/libx32
   0 lrwxrwxrwx   1 root root    8 Aug 24 12:27 sbin -> usr/sbin

Yes, I do. They're symliked to /usr.

tlmiller76 · 2021-08-24 21:45

Yup, then it's already running the merged layout.

Q4OS Forum

#1 2021-08-24 16:35

The Case for the /usr Merge

#2 2021-08-24 17:05

Re: The Case for the /usr Merge

#3 2021-08-24 18:33

Re: The Case for the /usr Merge

#4 2021-08-24 20:31

Re: The Case for the /usr Merge

#5 2021-08-24 21:42

Re: The Case for the /usr Merge

#6 2021-08-24 21:45

Re: The Case for the /usr Merge

Board footer