* Re: [gentoo-project] Call for agenda items -- Council meeting 13-11-2012
@ 2012-10-30 16:38 99% ` William Hubbs
0 siblings, 0 replies; 1+ results
From: William Hubbs @ 2012-10-30 16:38 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1: Type: text/plain, Size: 2741 bytes --]
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
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2012-10-30 15:00 [gentoo-project] Call for agenda items -- Council meeting 13-11-2012 Fabian Groffen
2012-10-30 15:36 ` William Hubbs
2012-10-30 16:21 ` Ian Stakenvicius
2012-10-30 16:38 99% ` William Hubbs
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox