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.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to