On Tue, Oct 30, 2012 at 11:38:20AM -0500, William Hubbs wrote:
> On Tue, Oct 30, 2012 at 12:21:00PM -0400, Ian Stakenvicius wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> > 
> > On 30/10/12 11:36 AM, William Hubbs wrote:
> > > Fellow Council Members:
> > > 
> > > We now have two methods of handling separate /usr configurations
> > > on Linux in the tree.
> > > 
> > > The first, and by far, the most flexable method is to use an
> > > initramfs. This method is now documented in the initramfs guide [1]
> > > and the handbooks. It would need to be used if a user needs
> > > specialized drivers running or modules loaded before the / or /usr
> > > file systems can be accessed. A non-inclusive list of these
> > > situations would be RAID, LVM2, ZFS, and software for encrypted
> > > file systems.
> > > 
> > > The second method can be used if the flexability of the first
> > > method is not needed. It involves re-emerging
> > > >=sys-apps/busybox-1.20.0 with the sep-usr use flag active and
> > > following the instructions in the elog messages. This is the way to
> > > support separate /usr without an initramfs if someone wants this.
> > > 
> > > The goal of separate /usr support is to insure that /usr is always 
> > > available when / is, and both of these methods meet this goal. If
> > > users switch to one of these methods, there is no further work
> > > required by us to support separate /usr configurations.
> > > 
> > > I have gone over this with Diego in QA, and he agrees that these
> > > are the methods we should use. That is why he is on the cc:
> > > specifically for this email.
> > > 
> > > I believe the only remaining step is for the council to approve
> > > this plan, so I would like it to be added to the agenda.
> > > 
> > > If this is approved, my plan will be to release a news item then 
> > > give a time window for users to read the news item and make their 
> > > decision [2]. Once the time window expires, we could assume that
> > > users with separate /usr have switched to using one of these two
> > > methods of supporting it.
> > > 
> > 
> > The end result of this assumption is that the use of
> > gen_usr_ldscript() and the move of libs from /usr/lib to /lib will
> > become deprecated, correct?  I think it's pertinent to note this (or
> > whatever other changes will then be requested/required for Council to
> > decide on) within this discussion, if not also within the "plan"..
> 
> On Linux, yes, you are correct. I wouldn't propose touching it for the
> *bsd platforms.
> 
> Also, once everyone switches over, this deprecation would be
> transparent. The calls to gen_usr_ldscript would be removed from
> ebuilds where possible, and the function itself could be disabled on
> linux. Once this is done, when packages are rebuilt, the libraries would
> migrate back to /usr/lib.
> 
> William
> 

After further research, we can't implement the initramfs yet for stable
users, because there isn't a stable  version of genkernel which mounts
/usr. So, I would like to change my plan for handling this slightly.

We can't move until a stable version of genkernel supports mounting
/usr. Once that happens, the newsitem will be released and there would
be a time window given, which would be up for discussion, but I think it
should be 30 days.

Other than that, the same proposal stands.

Thanks,

William