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. 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. > 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. > Michael/veremit. > > On 05/04/16 02:19, William Hubbs wrote: >> All, >> >> I thought that since the usr merge is coming up again, and since I lost >> track of the message where it was brought up, I would open a >> new thread to discuss it. >> >> When it came up before, some were saying that the /usr merge violates >> the fhs. I don't remember the specifics of what the claim was at the >> time, (I'm sure someone will point it out if it is still a concern). >> >> I don't think creating usr merged stages would be that difficult. I >> think it would just be a matter of creating a new version of baselayout >> that puts these symlinks in place: >> >> /bin->usr/bin >> /lib->usr/lib >> /lib32->usr/lib32 >> /lib64->usr/lib64 >> /sbin->usr/bin >> /usr/sbin->bin >> >> Once that is in place in a new baselayout, I think portage's colission >> detection would be able to catch files that had the same names and were >> originally in different paths when building the new stages. >> >> I put some thought also in how to nigrate live systems, and I'm not sure >> what the best way to do that is. I wrote a script, which would do it in >> theory, but I haven't tested because I only have one system and if >> it breaks it the only way back would be to reinstall. >> >> The script is attached. >> >> >> Thoughts on any of this? >> >> William >> > >
