From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 75F9659CAF for ; Wed, 6 Apr 2016 20:49:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1EA4021C0DD; Wed, 6 Apr 2016 20:48:59 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 14B1221C0D1 for ; Wed, 6 Apr 2016 20:48:57 +0000 (UTC) Received: from localhost (unknown [100.42.103.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: williamh) by smtp.gentoo.org (Postfix) with ESMTPSA id E33E2340DA7 for ; Wed, 6 Apr 2016 20:48:54 +0000 (UTC) Date: Wed, 6 Apr 2016 15:43:10 -0500 From: William Hubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] usr merge Message-ID: <20160406204310.GA11167@whubbs1.gaikai.biz> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <570312c8.1469ca0a.30985.5db1@mx.google.com> <570523FD.3040703@iee.org> <570530D4.4030803@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: <570530D4.4030803@gentoo.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Archives-Salt: 78984859-d6a4-43a9-9f1a-dc361d99947f X-Archives-Hash: 74847285af09883d9bfd2a67d8ec411f --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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). >=20 > 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. >=20 > 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. >=20 > Gentoo systems managed this way will suffer from multiple problems: >=20 > * Software updates that change the configuration file format without > supporting the older format will break. >=20 > * Software updates that change the boot scripts will break. >=20 > * Future baselayout updates will not be able to touch anything outside > of /usr and anything requiring such things be touched will break. >=20 > * An update to /usr that adds new software will fail to include things > outside of /usr, like the boot scripts and configuration files. >=20 > * 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. >=20 > 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. >=20 > 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. >=20 > 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. =20 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. >=20 > 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 RHE= L. [1] https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlcFdN4ACgkQblQW9DDEZTjPbQCfeS0wVl2n8pyzoZd9Oj/Zh9Wd TvEAn2PLVeHZJDblPCH3lvbgKKx3/hJT =WO0D -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn--