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 4152559CAF for ; Wed, 6 Apr 2016 16:57:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4AD3721C0BC; Wed, 6 Apr 2016 16:57:28 +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 4A35A21C0AF for ; Wed, 6 Apr 2016 16:57:27 +0000 (UTC) Received: from localhost (dra13-4-78-234-166-189.fbx.proxad.net [78.234.166.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 15E3E340E3F for ; Wed, 6 Apr 2016 16:57:24 +0000 (UTC) From: Alexis Ballier To: Subject: Re: [gentoo-dev] usr merge Date: Wed, 06 Apr 2016 18:57:20 +0200 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 Message-ID: In-Reply-To: <57053A65.7010903@gentoo.org> References: <570312c8.1469ca0a.30985.5db1@mx.google.com> <570523FD.3040703@iee.org> <00dd8d2f-a8a8-4fab-b7a6-c72466d62532@gentoo.org> <5705340B.6090800@gentoo.org> <0e611768-d5fc-4283-853f-929a49c97692@gentoo.org> <57053A65.7010903@gentoo.org> Organization: Gentoo User-Agent: Trojita/0.6; Qt/5.5.1; xcb; Linux; Gentoo Base System release 2.2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 95c6b43f-fd62-454b-b4b2-45333fe63b52 X-Archives-Hash: 732f4dec29d676cb41158d2c7f1ff396 On Wednesday, April 6, 2016 6:33:41 PM CEST, Richard Yao wrote: > On 04/06/2016 12:20 PM, Alexis Ballier wrote: >> On Wednesday, April 6, 2016 6:06:35 PM CEST, Richard Yao wrote: >> ... > > Leveraging the /usr merge to enable easier updating of multiple systems > means that you are updating a Gentoo system image on a build server, > snapshotting /usr both before/after the update and then distributing the > delta on /usr to other systems without any of the changes that occurred > outside of /usr. A proper update requires finding all of those changes > and then applying them manually. That really is not the same thing that > RHEL and Solaris have, where the necessity of propagating changes > outside of /usr is minimized by having none to propagate. > > I do not understand how CONFIG_PROTECT is relevant here. Whatever > CONFIG_PROTECT did was done on the build system. The systems receiving > the updates via ZFS send/recv or some similar mechanism are not going to > have CONFIG_PROTECT evaluated. Even if it were somehow evaluated, all of > the paths in CONFIG_PROTECT should be outside of /usr anyway. Exactly. CONFIG_PROTECT requires admins to (sort of) manually merge /etc=20 changes. If you want all changes on the build server to be magically=20 propagated to clients, then share it over nfs or whatever is your prefered=20= mechanism. This is not a great idea though, FHS is quite clear on the=20 matter: /etc : Host-specific system configuration usr-merge does not deal with that at all. usr-merge deals with the=20 intracate dependencies of /usr onto /lib, /bin, etc. by simply removing=20 them. If you want to share everything, then use nfsroot and mount local=20 disks by label.