| 1 |
On 04/06/2016 12:20 PM, Alexis Ballier wrote: |
| 2 |
> On Wednesday, April 6, 2016 6:06:35 PM CEST, Richard Yao wrote: |
| 3 |
> |
| 4 |
>> That is unless you put per-system state in /usr/local, do symlinks to it |
| 5 |
>> in / and mount /usr/local as part of system boot, which is the other way |
| 6 |
>> of doing this. I have seen a variant of this done in asuswrt-merlin on |
| 7 |
>> routers. |
| 8 |
> |
| 9 |
> This doesnt seem to have anything to do with what I was describing. |
| 10 |
> |
| 11 |
> Another option I'm using a lot is nfsroot. This doesn't have the same |
| 12 |
> level of flexibility: running multiple hosts with nfsroot and thus |
| 13 |
> shared /etc/fstab tends to be annoying. |
| 14 |
> |
| 15 |
>>> See https://fedoraproject.org/wiki/Features/UsrMove for a more complete |
| 16 |
>>> discussion. |
| 17 |
>> |
| 18 |
>> That does not address the problems of supporting this configuration in a |
| 19 |
>> rolling release. |
| 20 |
>> |
| 21 |
>> Formats in /etc can fall out of sync with software in /usr. If boot |
| 22 |
>> options change, the stuff in /etc/init.d is not updated. If you add |
| 23 |
>> software, the update to /etc/init.d is omitted. If you have a baselayout |
| 24 |
>> change, it is not propagated. |
| 25 |
> |
| 26 |
> Ever heard of CONFIG_PROTECT ? :) What you describe is already what |
| 27 |
> happens and what most people want. |
| 28 |
|
| 29 |
Leveraging the /usr merge to enable easier updating of multiple systems |
| 30 |
means that you are updating a Gentoo system image on a build server, |
| 31 |
snapshotting /usr both before/after the update and then distributing the |
| 32 |
delta on /usr to other systems without any of the changes that occurred |
| 33 |
outside of /usr. A proper update requires finding all of those changes |
| 34 |
and then applying them manually. That really is not the same thing that |
| 35 |
RHEL and Solaris have, where the necessity of propagating changes |
| 36 |
outside of /usr is minimized by having none to propagate. |
| 37 |
|
| 38 |
I do not understand how CONFIG_PROTECT is relevant here. Whatever |
| 39 |
CONFIG_PROTECT did was done on the build system. The systems receiving |
| 40 |
the updates via ZFS send/recv or some similar mechanism are not going to |
| 41 |
have CONFIG_PROTECT evaluated. Even if it were somehow evaluated, all of |
| 42 |
the paths in CONFIG_PROTECT should be outside of /usr anyway. |
Archives