>> 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.
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.
> 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.
Only a masochist would want to do this right now. There are saner ways of doing
things with the legacy layout than the Solaris way that depends on the /usr
merge.
>>> 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/
