1 |
On Tue, Oct 30, 2012 at 11:38:20AM -0500, William Hubbs wrote: |
2 |
> On Tue, Oct 30, 2012 at 12:21:00PM -0400, Ian Stakenvicius wrote: |
3 |
> > -----BEGIN PGP SIGNED MESSAGE----- |
4 |
> > Hash: SHA256 |
5 |
> > |
6 |
> > On 30/10/12 11:36 AM, William Hubbs wrote: |
7 |
> > > Fellow Council Members: |
8 |
> > > |
9 |
> > > We now have two methods of handling separate /usr configurations |
10 |
> > > on Linux in the tree. |
11 |
> > > |
12 |
> > > The first, and by far, the most flexable method is to use an |
13 |
> > > initramfs. This method is now documented in the initramfs guide [1] |
14 |
> > > and the handbooks. It would need to be used if a user needs |
15 |
> > > specialized drivers running or modules loaded before the / or /usr |
16 |
> > > file systems can be accessed. A non-inclusive list of these |
17 |
> > > situations would be RAID, LVM2, ZFS, and software for encrypted |
18 |
> > > file systems. |
19 |
> > > |
20 |
> > > The second method can be used if the flexability of the first |
21 |
> > > method is not needed. It involves re-emerging |
22 |
> > > >=sys-apps/busybox-1.20.0 with the sep-usr use flag active and |
23 |
> > > following the instructions in the elog messages. This is the way to |
24 |
> > > support separate /usr without an initramfs if someone wants this. |
25 |
> > > |
26 |
> > > The goal of separate /usr support is to insure that /usr is always |
27 |
> > > available when / is, and both of these methods meet this goal. If |
28 |
> > > users switch to one of these methods, there is no further work |
29 |
> > > required by us to support separate /usr configurations. |
30 |
> > > |
31 |
> > > I have gone over this with Diego in QA, and he agrees that these |
32 |
> > > are the methods we should use. That is why he is on the cc: |
33 |
> > > specifically for this email. |
34 |
> > > |
35 |
> > > I believe the only remaining step is for the council to approve |
36 |
> > > this plan, so I would like it to be added to the agenda. |
37 |
> > > |
38 |
> > > If this is approved, my plan will be to release a news item then |
39 |
> > > give a time window for users to read the news item and make their |
40 |
> > > decision [2]. Once the time window expires, we could assume that |
41 |
> > > users with separate /usr have switched to using one of these two |
42 |
> > > methods of supporting it. |
43 |
> > > |
44 |
> > |
45 |
> > The end result of this assumption is that the use of |
46 |
> > gen_usr_ldscript() and the move of libs from /usr/lib to /lib will |
47 |
> > become deprecated, correct? I think it's pertinent to note this (or |
48 |
> > whatever other changes will then be requested/required for Council to |
49 |
> > decide on) within this discussion, if not also within the "plan".. |
50 |
> |
51 |
> On Linux, yes, you are correct. I wouldn't propose touching it for the |
52 |
> *bsd platforms. |
53 |
> |
54 |
> Also, once everyone switches over, this deprecation would be |
55 |
> transparent. The calls to gen_usr_ldscript would be removed from |
56 |
> ebuilds where possible, and the function itself could be disabled on |
57 |
> linux. Once this is done, when packages are rebuilt, the libraries would |
58 |
> migrate back to /usr/lib. |
59 |
> |
60 |
> William |
61 |
> |
62 |
|
63 |
After further research, we can't implement the initramfs yet for stable |
64 |
users, because there isn't a stable version of genkernel which mounts |
65 |
/usr. So, I would like to change my plan for handling this slightly. |
66 |
|
67 |
We can't move until a stable version of genkernel supports mounting |
68 |
/usr. Once that happens, the newsitem will be released and there would |
69 |
be a time window given, which would be up for discussion, but I think it |
70 |
should be 30 days. |
71 |
|
72 |
Other than that, the same proposal stands. |
73 |
|
74 |
Thanks, |
75 |
|
76 |
William |