| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 30/10/12 11:36 AM, William Hubbs wrote: |
| 5 |
> Fellow Council Members: |
| 6 |
> |
| 7 |
> We now have two methods of handling separate /usr configurations |
| 8 |
> on Linux in the tree. |
| 9 |
> |
| 10 |
> The first, and by far, the most flexable method is to use an |
| 11 |
> initramfs. This method is now documented in the initramfs guide [1] |
| 12 |
> and the handbooks. It would need to be used if a user needs |
| 13 |
> specialized drivers running or modules loaded before the / or /usr |
| 14 |
> file systems can be accessed. A non-inclusive list of these |
| 15 |
> situations would be RAID, LVM2, ZFS, and software for encrypted |
| 16 |
> file systems. |
| 17 |
> |
| 18 |
> The second method can be used if the flexability of the first |
| 19 |
> method is not needed. It involves re-emerging |
| 20 |
> >=sys-apps/busybox-1.20.0 with the sep-usr use flag active and |
| 21 |
> following the instructions in the elog messages. This is the way to |
| 22 |
> support separate /usr without an initramfs if someone wants this. |
| 23 |
> |
| 24 |
> The goal of separate /usr support is to insure that /usr is always |
| 25 |
> available when / is, and both of these methods meet this goal. If |
| 26 |
> users switch to one of these methods, there is no further work |
| 27 |
> required by us to support separate /usr configurations. |
| 28 |
> |
| 29 |
> I have gone over this with Diego in QA, and he agrees that these |
| 30 |
> are the methods we should use. That is why he is on the cc: |
| 31 |
> specifically for this email. |
| 32 |
> |
| 33 |
> I believe the only remaining step is for the council to approve |
| 34 |
> this plan, so I would like it to be added to the agenda. |
| 35 |
> |
| 36 |
> If this is approved, my plan will be to release a news item then |
| 37 |
> give a time window for users to read the news item and make their |
| 38 |
> decision [2]. Once the time window expires, we could assume that |
| 39 |
> users with separate /usr have switched to using one of these two |
| 40 |
> methods of supporting it. |
| 41 |
> |
| 42 |
|
| 43 |
The end result of this assumption is that the use of |
| 44 |
gen_usr_ldscript() and the move of libs from /usr/lib to /lib will |
| 45 |
become deprecated, correct? I think it's pertinent to note this (or |
| 46 |
whatever other changes will then be requested/required for Council to |
| 47 |
decide on) within this discussion, if not also within the "plan".. |
| 48 |
|
| 49 |
|
| 50 |
|
| 51 |
-----BEGIN PGP SIGNATURE----- |
| 52 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 53 |
|
| 54 |
iF4EAREIAAYFAlCP/msACgkQ2ugaI38ACPBEWgEAhz3bZDerxT/8bVt+1YzMoeDs |
| 55 |
osrzwFXdi+06vF8MTjQBAI79FHc6IO3hjk9kbqD96Urh73zR1WCI2DtlpSypXBvj |
| 56 |
=ZgY/ |
| 57 |
-----END PGP SIGNATURE----- |
Archives