On 04/06/2016 12:06 PM, Richard Yao wrote: > On 04/06/2016 11:11 AM, Alexis Ballier wrote: >> On Wednesday, April 6, 2016 4:58:05 PM CEST, M. J. Everitt wrote: >>> What, if any, is the benefit of squashing /usr out of the equation? I >>> happen to have a few workstations that load their /usr off an NFS share >>> presently, >> >> >> This is precisely one case where I see benefits: no need to correlate / >> and /usr. >> >> With the current way, this setup is broken if you don't pay attention: >> glibc is not backwards compatible (that is, stuff built for glibc 2.22 >> is not guaranteed to work with 2.21 and less), but you have glibc in >> /lib and stuff in /usr linking and dynamically loading it. If your nfs >> server updates glibc, you have to update every / on every of your >> workstations or fear the consequences of running binaries built for 2.22 >> but running against an older version. >> > > That is unless you put per-system state in /usr/local, do symlinks to it > in / and mount /usr/local as part of system boot, which is the other way > of doing this. I have seen a variant of this done in asuswrt-merlin on > routers. > >> See https://fedoraproject.org/wiki/Features/UsrMove for a more complete >> discussion. > > That does not address the problems of supporting this configuration in a > rolling release. > > Formats in /etc can fall out of sync with software in /usr. If boot > options change, the stuff in /etc/init.d is not updated. If you add > software, the update to /etc/init.d is omitted. If you have a baselayout > change, it is not propagated. Whether or not the package manager can be > used is not discussed. It definitely can be in Solaris when this feature > is used in Solaris zones, although I am not sure how that interacts with > updates as I never looked. I do not have a VM with a member of the > OpenSolaris family handy to check. > > Solaris and RHEL will see the benefits described on the Fedora page > because they handled many of those problems. In most cases, they handled > it by being stale non-rolling releases that do not support major version > upgrades. Fedora handled it by having a disclaimer that things should be > expected to break across Fedora versions. Neither are things that I > expect us to do, so if we adopt this, we will need to do something > entirely new to be able to gain these benefits.
To say it clearly, lets not claim that the /usr merge will give us any of the benefits mentioned in the Fedora wiki unless we have a plan to handle the complications that being a rolling distribution poses for doing atomic updates via the mechanism invented in Solaris on a post-/usr merge system. On a non-rolling system release like Solaris or RHEL, you need to install information on how to boot daemons with default configurations in /usr and let users override things in /etc in addition to the /usr merge to gain the capabilities cited on the Fedora wiki page. You get bonus points if a clone of a snapshot can be used to make a container with a working package manager, but could otherwise define that configuration as being unsupported or write a script to install it. On a rolling release like Gentoo, rearranging the system baselayout is also insufficient, but there are many more problems than those that occur on a non-rolling system release. I listed most of those in my previous email.
