On Wed, Apr 06, 2016 at 11:52:52AM -0400, Richard Yao wrote: > On 04/06/2016 10:58 AM, 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, with some bodgery-workarounds I did pre the udev notification > > about initramfs's which I have never got around to implementing > > (although I'm pretty sure I have the tools now to do, along with UUIDs > > for boot media). > > The idea in Solaris is to enable atomic updates via the /usr mount > without touching data files in /etc or temporary files in /var. Usually, > this would be done on reboot and could be propagated to many systems > either via /usr on NFS or ZFS send/recv. > > This works well on Solaris because both software versions are pegged > (such that file formats in /etc are stable) in favor of backported fixes > and the FHS does not change across major OS versions. The same goes for > RHEL.
Also, there are other benefits to the /usr merge [1]. Note, we are not
talking about squashing /usr out of the equasion, but merging /bin,
/sbin and /lib* into their counterparts in /usr and creating symlinks in
the root directory pointing to the counterparts in /usr.
>
> Gentoo systems managed this way will suffer from multiple problems:
>
> * Software updates that change the configuration file format without
> supporting the older format will break.
>
> * Software updates that change the boot scripts will break.
>
> * Future baselayout updates will not be able to touch anything outside
> of /usr and anything requiring such things be touched will break.
>
> * An update to /usr that adds new software will fail to include things
> outside of /usr, like the boot scripts and configuration files.
>
> * The package database will fall out of sync with /usr (or be broken
> period). Presumably, if you are updating this way, you should expect the
> package database to be broken.
>
> These are likely to be mostly fixable, but I do not think we have a plan
> in place to fix them right now. The general staleness of Solaris and
> RHEL handle the first 3 issues for them for free.
>
> I have not looked at the specifics of how Solaris handles the 4th, but I
> know that SMF in OpenSolaris descendents will update manifests on first
> boot into a new boot environment. That suggests to me that the Solaris
> boot scripts handle it by comparing /etc with /usr.
>
> As for the 5th, the package database is not broken in Solaris zones
> where the /usr merge is leveraged to enable easy updates. However, I do
> not know how updating all zones works when zones have independently
> installed software. It might be that the software is installed in
> /usr/local inside the zone and conflicts are the user's problem, but it
> has been so long since I used an illumos distribution (which is
> descended from OpenSolaris) that I do not remember.
I don't think any of these issues are issues that Gentoo systems
managed like this do not already have.
If you are mounting /usr from nfs right now, for example,
things are worse, because you also have to worry about whether packages
split their installations between /usr/lib*->/lib* and
/usr/{,s}bin->/{s,}bin.
> > Whilst these aren't currently scheduled for upgrade, I don't personally
> > see any merit, given discussions here about work needed to 'shore up' a
> > change to match some particular use case. I would therefore definitely
> > agree with those that have proposed that this is an Option and not a
> > standard gentoo install item unless there are some specific caveats that
> > this solves.
>
> The original purpose of the /usr merge in Solaris was to make managing
> updates easier. Redhat realized that and copied it. Copying it too
> without doing the enabling work necessary for a rolling distribution
> would be setting a trap for users who would think that they can manage
> deployments of Gentoo like they can manage deployments Solaris and/or RHEL.
[1]
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
signature.asc
Description: Digital signature
