1 |
On Wed, Apr 06, 2016 at 11:52:52AM -0400, Richard Yao wrote: |
2 |
> On 04/06/2016 10:58 AM, M. J. Everitt wrote: |
3 |
> > What, if any, is the benefit of squashing /usr out of the equation? I |
4 |
> > happen to have a few workstations that load their /usr off an NFS share |
5 |
> > presently, with some bodgery-workarounds I did pre the udev notification |
6 |
> > about initramfs's which I have never got around to implementing |
7 |
> > (although I'm pretty sure I have the tools now to do, along with UUIDs |
8 |
> > for boot media). |
9 |
> |
10 |
> The idea in Solaris is to enable atomic updates via the /usr mount |
11 |
> without touching data files in /etc or temporary files in /var. Usually, |
12 |
> this would be done on reboot and could be propagated to many systems |
13 |
> either via /usr on NFS or ZFS send/recv. |
14 |
> |
15 |
> This works well on Solaris because both software versions are pegged |
16 |
> (such that file formats in /etc are stable) in favor of backported fixes |
17 |
> and the FHS does not change across major OS versions. The same goes for |
18 |
> RHEL. |
19 |
|
20 |
Also, there are other benefits to the /usr merge [1]. Note, we are not |
21 |
talking about squashing /usr out of the equasion, but merging /bin, |
22 |
/sbin and /lib* into their counterparts in /usr and creating symlinks in |
23 |
the root directory pointing to the counterparts in /usr. |
24 |
|
25 |
> |
26 |
> Gentoo systems managed this way will suffer from multiple problems: |
27 |
> |
28 |
> * Software updates that change the configuration file format without |
29 |
> supporting the older format will break. |
30 |
> |
31 |
> * Software updates that change the boot scripts will break. |
32 |
> |
33 |
> * Future baselayout updates will not be able to touch anything outside |
34 |
> of /usr and anything requiring such things be touched will break. |
35 |
> |
36 |
> * An update to /usr that adds new software will fail to include things |
37 |
> outside of /usr, like the boot scripts and configuration files. |
38 |
> |
39 |
> * The package database will fall out of sync with /usr (or be broken |
40 |
> period). Presumably, if you are updating this way, you should expect the |
41 |
> package database to be broken. |
42 |
> |
43 |
> These are likely to be mostly fixable, but I do not think we have a plan |
44 |
> in place to fix them right now. The general staleness of Solaris and |
45 |
> RHEL handle the first 3 issues for them for free. |
46 |
> |
47 |
> I have not looked at the specifics of how Solaris handles the 4th, but I |
48 |
> know that SMF in OpenSolaris descendents will update manifests on first |
49 |
> boot into a new boot environment. That suggests to me that the Solaris |
50 |
> boot scripts handle it by comparing /etc with /usr. |
51 |
> |
52 |
> As for the 5th, the package database is not broken in Solaris zones |
53 |
> where the /usr merge is leveraged to enable easy updates. However, I do |
54 |
> not know how updating all zones works when zones have independently |
55 |
> installed software. It might be that the software is installed in |
56 |
> /usr/local inside the zone and conflicts are the user's problem, but it |
57 |
> has been so long since I used an illumos distribution (which is |
58 |
> descended from OpenSolaris) that I do not remember. |
59 |
|
60 |
I don't think any of these issues are issues that Gentoo systems |
61 |
managed like this do not already have. |
62 |
If you are mounting /usr from nfs right now, for example, |
63 |
things are worse, because you also have to worry about whether packages |
64 |
split their installations between /usr/lib*->/lib* and |
65 |
/usr/{,s}bin->/{s,}bin. |
66 |
|
67 |
> > Whilst these aren't currently scheduled for upgrade, I don't personally |
68 |
> > see any merit, given discussions here about work needed to 'shore up' a |
69 |
> > change to match some particular use case. I would therefore definitely |
70 |
> > agree with those that have proposed that this is an Option and not a |
71 |
> > standard gentoo install item unless there are some specific caveats that |
72 |
> > this solves. |
73 |
> |
74 |
> The original purpose of the /usr merge in Solaris was to make managing |
75 |
> updates easier. Redhat realized that and copied it. Copying it too |
76 |
> without doing the enabling work necessary for a rolling distribution |
77 |
> would be setting a trap for users who would think that they can manage |
78 |
> deployments of Gentoo like they can manage deployments Solaris and/or RHEL. |
79 |
|
80 |
[1] |
81 |
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ |