From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id AC11C138010 for ; 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 ; 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 ; Tue, 30 Oct 2012 16:38:25 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id un3so449667obb.40 for ; 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 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 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: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list 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--