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 511FE138010 for ; Fri, 2 Nov 2012 18:02:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BEB2A21C0C4 for ; Fri, 2 Nov 2012 18:02:11 +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 6AC5121C002 for ; Fri, 2 Nov 2012 17:22:50 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id un3so3727005obb.40 for ; Fri, 02 Nov 2012 10:22:49 -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=foUBZEpznVRaIRhu+1TlQ1OpPweR/tCarK92CjW3qPk=; b=ZF8O3fC6rF2noLa7faDoBpDU/aRq760vG16hEESOD5AHZNAEGE6vuiY2HW8GcUBr55 /Y4t2IXkAhp7x9yxvbQ8L51ON7ePJodR0SxkYON7LuxZ7yJOcdDr6DguopLiGjb/BvvE XvujYcaXWMXYaCtO7aKUlha7AhGJB7sg55Z+CjCKrWiQRTfw5vkpjQiq0Eanp1lVK566 p2VHVttpmNxRWEpGT0c7GKwUS2x/ojHWrPvckoe9zlUHgz/tst2mjp57IoYM2rosTTD+ tM8s0zMz30tXp/RYrvrqrwcYTj0FHF4FFZJrz+pQbyfvVmLOrAX+qm/BywBN+nJmWNn3 NhwQ== Received: by 10.182.89.42 with SMTP id bl10mr1932313obb.27.1351876969699; Fri, 02 Nov 2012 10:22:49 -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 bd5sm9677406obb.5.2012.11.02.10.22.46 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 10:22:48 -0700 (PDT) Sender: William Hubbs Received: by linux1 (sSMTP sendmail emulation); Fri, 02 Nov 2012 12:22:46 -0500 Date: Fri, 2 Nov 2012 12:22:46 -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: <20121102172246.GA6407@linux1> Mail-Followup-To: gentoo-project@lists.gentoo.org References: <20121030150024.GU85698@gentoo.org> <20121030153613.GA6948@linux1> <508FFE6C.4070200@gentoo.org> <20121030163820.GA7141@linux1> 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="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <20121030163820.GA7141@linux1> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: af3ec881-7ce2-4826-87fb-7be20391fd9d X-Archives-Hash: d0bd11749dc721aa2b6bffe2e053f36a --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 > >=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".. >=20 > On Linux, yes, you are correct. I wouldn't propose touching it for the > *bsd platforms. >=20 > 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. >=20 > William >=20 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 --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlCUAWYACgkQblQW9DDEZTi3ewCeO8Yfr9d/qfhR6AyefbqZ+KR2 ERQAmwWN/uemJmDIkSK3/Jm0/rBCsZ0l =THi5 -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j--