| 1 |
On 04/06/2016 10:58 AM, M. J. Everitt wrote: |
| 2 |
> What, if any, is the benefit of squashing /usr out of the equation? I |
| 3 |
> happen to have a few workstations that load their /usr off an NFS share |
| 4 |
> presently, with some bodgery-workarounds I did pre the udev notification |
| 5 |
> about initramfs's which I have never got around to implementing |
| 6 |
> (although I'm pretty sure I have the tools now to do, along with UUIDs |
| 7 |
> for boot media). |
| 8 |
|
| 9 |
The idea in Solaris is to enable atomic updates via the /usr mount |
| 10 |
without touching data files in /etc or temporary files in /var. Usually, |
| 11 |
this would be done on reboot and could be propagated to many systems |
| 12 |
either via /usr on NFS or ZFS send/recv. |
| 13 |
|
| 14 |
This works well on Solaris because both software versions are pegged |
| 15 |
(such that file formats in /etc are stable) in favor of backported fixes |
| 16 |
and the FHS does not change across major OS versions. The same goes for |
| 17 |
RHEL. |
| 18 |
|
| 19 |
Gentoo systems managed this way will suffer from multiple problems: |
| 20 |
|
| 21 |
* Software updates that change the configuration file format without |
| 22 |
supporting the older format will break. |
| 23 |
|
| 24 |
* Software updates that change the boot scripts will break. |
| 25 |
|
| 26 |
* Future baselayout updates will not be able to touch anything outside |
| 27 |
of /usr and anything requiring such things be touched will break. |
| 28 |
|
| 29 |
* An update to /usr that adds new software will fail to include things |
| 30 |
outside of /usr, like the boot scripts and configuration files. |
| 31 |
|
| 32 |
* The package database will fall out of sync with /usr (or be broken |
| 33 |
period). Presumably, if you are updating this way, you should expect the |
| 34 |
package database to be broken. |
| 35 |
|
| 36 |
These are likely to be mostly fixable, but I do not think we have a plan |
| 37 |
in place to fix them right now. The general staleness of Solaris and |
| 38 |
RHEL handle the first 3 issues for them for free. |
| 39 |
|
| 40 |
I have not looked at the specifics of how Solaris handles the 4th, but I |
| 41 |
know that SMF in OpenSolaris descendents will update manifests on first |
| 42 |
boot into a new boot environment. That suggests to me that the Solaris |
| 43 |
boot scripts handle it by comparing /etc with /usr. |
| 44 |
|
| 45 |
As for the 5th, the package database is not broken in Solaris zones |
| 46 |
where the /usr merge is leveraged to enable easy updates. However, I do |
| 47 |
not know how updating all zones works when zones have independently |
| 48 |
installed software. It might be that the software is installed in |
| 49 |
/usr/local inside the zone and conflicts are the user's problem, but it |
| 50 |
has been so long since I used an illumos distribution (which is |
| 51 |
descended from OpenSolaris) that I do not remember. |
| 52 |
|
| 53 |
> Whilst these aren't currently scheduled for upgrade, I don't personally |
| 54 |
> see any merit, given discussions here about work needed to 'shore up' a |
| 55 |
> change to match some particular use case. I would therefore definitely |
| 56 |
> agree with those that have proposed that this is an Option and not a |
| 57 |
> standard gentoo install item unless there are some specific caveats that |
| 58 |
> this solves. |
| 59 |
|
| 60 |
The original purpose of the /usr merge in Solaris was to make managing |
| 61 |
updates easier. Redhat realized that and copied it. Copying it too |
| 62 |
without doing the enabling work necessary for a rolling distribution |
| 63 |
would be setting a trap for users who would think that they can manage |
| 64 |
deployments of Gentoo like they can manage deployments Solaris and/or RHEL. |
| 65 |
|
| 66 |
> Michael/veremit. |
| 67 |
> |
| 68 |
> On 05/04/16 02:19, William Hubbs wrote: |
| 69 |
>> All, |
| 70 |
>> |
| 71 |
>> I thought that since the usr merge is coming up again, and since I lost |
| 72 |
>> track of the message where it was brought up, I would open a |
| 73 |
>> new thread to discuss it. |
| 74 |
>> |
| 75 |
>> When it came up before, some were saying that the /usr merge violates |
| 76 |
>> the fhs. I don't remember the specifics of what the claim was at the |
| 77 |
>> time, (I'm sure someone will point it out if it is still a concern). |
| 78 |
>> |
| 79 |
>> I don't think creating usr merged stages would be that difficult. I |
| 80 |
>> think it would just be a matter of creating a new version of baselayout |
| 81 |
>> that puts these symlinks in place: |
| 82 |
>> |
| 83 |
>> /bin->usr/bin |
| 84 |
>> /lib->usr/lib |
| 85 |
>> /lib32->usr/lib32 |
| 86 |
>> /lib64->usr/lib64 |
| 87 |
>> /sbin->usr/bin |
| 88 |
>> /usr/sbin->bin |
| 89 |
>> |
| 90 |
>> Once that is in place in a new baselayout, I think portage's colission |
| 91 |
>> detection would be able to catch files that had the same names and were |
| 92 |
>> originally in different paths when building the new stages. |
| 93 |
>> |
| 94 |
>> I put some thought also in how to nigrate live systems, and I'm not sure |
| 95 |
>> what the best way to do that is. I wrote a script, which would do it in |
| 96 |
>> theory, but I haven't tested because I only have one system and if |
| 97 |
>> it breaks it the only way back would be to reinstall. |
| 98 |
>> |
| 99 |
>> The script is attached. |
| 100 |
>> |
| 101 |
>> |
| 102 |
>> Thoughts on any of this? |
| 103 |
>> |
| 104 |
>> William |
| 105 |
>> |
| 106 |
> |
| 107 |
> |
Archives