On Wed, Apr 06, 2016 at 05:36:09PM -0400, Richard Yao wrote: > > > >> On Apr 6, 2016, at 4:43 PM, William Hubbs <willi...@gentoo.org> wrote: > >> > >>> 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]. > > Are they worth breaking existing systems that are configured the one way we > all know things will break if this is forced? If not, a USE flag would work.
Other than systems using separate /usr without initramfs (which we
declared broken three years ago), I'm not following what "we all know"
would break.
> As for those benefits, they do little for {/usr,}/sbin vs {/usr,}/bin, which
> is where the incompatibilities tend to live. I encountered one of these in
> powertop the other day (patch pending). The benefits of being able to access
> things from both places are somewhat exaggerated given that compatibility
> among systems has long required searching $PATH and likely always will.
>
> > 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.
>
> While one guy did the reverse (and the reverse ought to be okay for those
> that want to do that), no one appears to think that adopting the reverse is
> what is being suggested. Having this sort of clarity on whether forcing this
> on everyone via baselayout update, just providing the option for those who
> want it or some combination of the two (e.g. a long transition period in
> which both are supported) is being discussed would be nice though. This is
> not a Boolean decision.
>
> >> 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.
>
> That is my point.
Then we agree that these issues are not regressions that the usr merge
would cause. They are issues possibly, but imo not relevant to whether we
go ahead with the /usr merge or not.
William
signature.asc
Description: Digital signature
