Gentoo Archives: gentoo-project

From: William Hubbs <williamh@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Call for agenda items -- Council meeting 13-11-2012
Date: Fri, 02 Nov 2012 18:02:12
Message-Id: 20121102172246.GA6407@linux1
In Reply to: Re: [gentoo-project] Call for agenda items -- Council meeting 13-11-2012 by William Hubbs
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