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
changes. If you want all changes on the build server to be magically
propagated to clients, then share it over nfs or whatever is your prefered
mechanism. This is not a great idea though, FHS is quite clear on the
matter: /etc : Host-specific system configuration
usr-merge does not deal with that at all. usr-merge deals with the
intracate dependencies of /usr onto /lib, /bin, etc. by simply removing
them. If you want to share everything, then use nfsroot and mount local
disks by label.
