Re: [gentoo-project] Call for agenda items -- Council meeting 13-11-2012

[William Hubbs]

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