| 1 |
On 04/06/2016 12:06 PM, Richard Yao wrote: |
| 2 |
> On 04/06/2016 11:11 AM, Alexis Ballier wrote: |
| 3 |
>> On Wednesday, April 6, 2016 4:58:05 PM CEST, M. J. Everitt wrote: |
| 4 |
>>> What, if any, is the benefit of squashing /usr out of the equation? I |
| 5 |
>>> happen to have a few workstations that load their /usr off an NFS share |
| 6 |
>>> presently, |
| 7 |
>> |
| 8 |
>> |
| 9 |
>> This is precisely one case where I see benefits: no need to correlate / |
| 10 |
>> and /usr. |
| 11 |
>> |
| 12 |
>> With the current way, this setup is broken if you don't pay attention: |
| 13 |
>> glibc is not backwards compatible (that is, stuff built for glibc 2.22 |
| 14 |
>> is not guaranteed to work with 2.21 and less), but you have glibc in |
| 15 |
>> /lib and stuff in /usr linking and dynamically loading it. If your nfs |
| 16 |
>> server updates glibc, you have to update every / on every of your |
| 17 |
>> workstations or fear the consequences of running binaries built for 2.22 |
| 18 |
>> but running against an older version. |
| 19 |
>> |
| 20 |
> |
| 21 |
> That is unless you put per-system state in /usr/local, do symlinks to it |
| 22 |
> in / and mount /usr/local as part of system boot, which is the other way |
| 23 |
> of doing this. I have seen a variant of this done in asuswrt-merlin on |
| 24 |
> routers. |
| 25 |
> |
| 26 |
>> See https://fedoraproject.org/wiki/Features/UsrMove for a more complete |
| 27 |
>> discussion. |
| 28 |
> |
| 29 |
> That does not address the problems of supporting this configuration in a |
| 30 |
> rolling release. |
| 31 |
> |
| 32 |
> Formats in /etc can fall out of sync with software in /usr. If boot |
| 33 |
> options change, the stuff in /etc/init.d is not updated. If you add |
| 34 |
> software, the update to /etc/init.d is omitted. If you have a baselayout |
| 35 |
> change, it is not propagated. Whether or not the package manager can be |
| 36 |
> used is not discussed. It definitely can be in Solaris when this feature |
| 37 |
> is used in Solaris zones, although I am not sure how that interacts with |
| 38 |
> updates as I never looked. I do not have a VM with a member of the |
| 39 |
> OpenSolaris family handy to check. |
| 40 |
> |
| 41 |
> Solaris and RHEL will see the benefits described on the Fedora page |
| 42 |
> because they handled many of those problems. In most cases, they handled |
| 43 |
> it by being stale non-rolling releases that do not support major version |
| 44 |
> upgrades. Fedora handled it by having a disclaimer that things should be |
| 45 |
> expected to break across Fedora versions. Neither are things that I |
| 46 |
> expect us to do, so if we adopt this, we will need to do something |
| 47 |
> entirely new to be able to gain these benefits. |
| 48 |
|
| 49 |
To say it clearly, lets not claim that the /usr merge will give us any |
| 50 |
of the benefits mentioned in the Fedora wiki unless we have a plan to |
| 51 |
handle the complications that being a rolling distribution poses for |
| 52 |
doing atomic updates via the mechanism invented in Solaris on a |
| 53 |
post-/usr merge system. |
| 54 |
|
| 55 |
On a non-rolling system release like Solaris or RHEL, you need to |
| 56 |
install information on how to boot daemons with default configurations |
| 57 |
in /usr and let users override things in /etc in addition to the /usr |
| 58 |
merge to gain the capabilities cited on the Fedora wiki page. You get |
| 59 |
bonus points if a clone of a snapshot can be used to make a container |
| 60 |
with a working package manager, but could otherwise define that |
| 61 |
configuration as being unsupported or write a script to install it. |
| 62 |
|
| 63 |
On a rolling release like Gentoo, rearranging the system baselayout is |
| 64 |
also insufficient, but there are many more problems than those that |
| 65 |
occur on a non-rolling system release. I listed most of those in my |
| 66 |
previous email. |
Archives