From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-project+bounces-2196-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	by finch.gentoo.org (Postfix) with ESMTP id AC11C138010
	for <garchives@archives.gentoo.org>; Tue, 30 Oct 2012 18:03:40 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 30682E064C
	for <garchives@archives.gentoo.org>; Tue, 30 Oct 2012 18:03:40 +0000 (UTC)
Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181])
	by pigeon.gentoo.org (Postfix) with ESMTP id 637BC21C054
	for <gentoo-project@lists.gentoo.org>; Tue, 30 Oct 2012 16:38:25 +0000 (UTC)
Received: by mail-ob0-f181.google.com with SMTP id un3so449667obb.40
        for <gentoo-project@lists.gentoo.org>; Tue, 30 Oct 2012 09:38:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=sender:date:from:to:subject:message-id:mail-followup-to:references
         :mime-version:content-type:content-disposition:in-reply-to
         :user-agent;
        bh=NUN6sc4txKLvB9Dv8fJcR98VCViGwqieBdRgL4tjneA=;
        b=D0TOjLXVrWwhBQJYps4JOKGR7GoU7IW7KOip3xDne3iApiRWGAvpt190m6+s/zkC/t
         sn42YY63lpVXBjfmCQZKyWA7HKn7XoQk5r7ASm/T9JWyXa+EsBTqP8Rd6Ww1wd9JOlZ+
         TimCfKVj/fyjhIRq4xcfPbOh0giZmppX55nPEe7V3+wyORPEixtx0Kjabx+zkSgUTTlz
         WWD83KBjLPe1T6xMffUNzEm4jdfuN/Beg2gUaMD56ISeiIEHTtR4Q9wFp1H1idAIktUc
         ACY9KucdMVxLZBg6em4p+bRAjRmA0guNUXr4PMF9CO4stkQy1dE4WYpgcostY24GvDPG
         ZSOw==
Received: by 10.182.89.42 with SMTP id bl10mr28115107obb.27.1351615104792;
        Tue, 30 Oct 2012 09:38:24 -0700 (PDT)
Received: from linux1 (cpe-76-187-95-60.tx.res.rr.com. [76.187.95.60])
        by mx.google.com with ESMTPS id n7sm975817obd.16.2012.10.30.09.38.21
        (version=SSLv3 cipher=OTHER);
        Tue, 30 Oct 2012 09:38:23 -0700 (PDT)
Sender: William Hubbs <w.d.hubbs@gmail.com>
Received: by linux1 (sSMTP sendmail emulation); Tue, 30 Oct 2012 11:38:20 -0500
Date: Tue, 30 Oct 2012 11:38:20 -0500
From: William Hubbs <williamh@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] Call for agenda items -- Council meeting
 13-11-2012
Message-ID: <20121030163820.GA7141@linux1>
Mail-Followup-To: gentoo-project@lists.gentoo.org
References: <20121030150024.GU85698@gentoo.org>
 <20121030153613.GA6948@linux1>
 <508FFE6C.4070200@gentoo.org>
Precedence: bulk
List-Post: <mailto:gentoo-project@lists.gentoo.org>
List-Help: <mailto:gentoo-project+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-project+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-project+subscribe@lists.gentoo.org>
List-Id: Gentoo Project discussion list <gentoo-project.gentoo.org>
X-BeenThere: gentoo-project@lists.gentoo.org
Reply-To: gentoo-project@lists.gentoo.org
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW"
Content-Disposition: inline
In-Reply-To: <508FFE6C.4070200@gentoo.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Archives-Salt: 14540e61-8e4e-444e-b363-5be929d1eb35
X-Archives-Hash: 1f2539b68799d69ab66a9a26b7740d90


--0F1p//8PRICkK4MW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 30, 2012 at 12:21:00PM -0400, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>=20
> On 30/10/12 11:36 AM, William Hubbs wrote:
> > Fellow Council Members:
> >=20
> > We now have two methods of handling separate /usr configurations
> > on Linux in the tree.
> >=20
> > 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.
> >=20
> > The second method can be used if the flexability of the first
> > method is not needed. It involves re-emerging
> > >=3Dsys-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.
> >=20
> > The goal of separate /usr support is to insure that /usr is always=20
> > 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.
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > If this is approved, my plan will be to release a news item then=20
> > give a time window for users to read the news item and make their=20
> > 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.
> >=20
>=20
> 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


--0F1p//8PRICkK4MW
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlCQAnwACgkQblQW9DDEZTjJSQCgolI4GXkJoBJFhmDEIQkzggNN
xLwAnR8fVdIdlvZbkLU0K3MzTPQMagjN
=rCTG
-----END PGP SIGNATURE-----

--0F1p//8PRICkK4MW--