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 677DA1381F3 for ; Fri, 9 Nov 2012 18:03:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 03D77E05F8 for ; Fri, 9 Nov 2012 18:03:06 +0000 (UTC) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B850D21C00E for ; Fri, 9 Nov 2012 17:01:54 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id j6so4113318oag.40 for ; Fri, 09 Nov 2012 09:01:53 -0800 (PST) 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=9hghm8TZ6iXQbPC15j9S4ZWPm9o+FnqwQqZPRCJffts=; b=k/Gt1/eXtGNdUpLcxXmY0SVosscKVmbuSFpVt0T4FqfFAf0zb0EkYJzjpRPS4P4ELc 2eAsUz8BaYcJ8OBNddgD4lMKeiJApWaegAsAj1W2VArS/sRIuKzuZOaj1rKxT0qMSp7H GjL50hb1d5NGCiS7CpqnK6V2jSnzMusn2TQADU2V9oozlj144FJurl3q0YCE3kRc0kG/ Egyc412eMaCK9COnwvmpim+mcRLzrvXYzHS/XtLoyAeYAwwwemAT+D0orLtEN+qhwEuB MYqgCJRaun0nmlxMhLjnUUntQorPmx7PVqwc7YzfDmTGi4Ogkc5MVLX/Nb/YU3DZjKAx OxHA== Received: by 10.60.5.138 with SMTP id s10mr8152486oes.80.1352480513751; Fri, 09 Nov 2012 09:01:53 -0800 (PST) Received: from linux1 (cpe-76-187-95-60.tx.res.rr.com. [76.187.95.60]) by mx.google.com with ESMTPS id zy9sm6113947oeb.4.2012.11.09.09.01.49 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2012 09:01:52 -0800 (PST) Sender: William Hubbs Received: by linux1 (sSMTP sendmail emulation); Fri, 09 Nov 2012 11:01:49 -0600 Date: Fri, 9 Nov 2012 11:01:49 -0600 From: William Hubbs To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC Message-ID: <20121109170149.GA22128@linux1> Mail-Followup-To: gentoo-project@lists.gentoo.org References: <20121106212816.GE82762@gentoo.org> <20121108174548.GB3842@linux1> <20121108181557.GP83592@gentoo.org> <20121108185348.GB3931@linux1> <20121108204629.5ae6765d@gentoo.org> <20121109051346.GA20124@linux1> <20121109083355.248ffbe3@gentoo.org> <20121109153247.GA21483@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="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 1c4dce2d-d318-4e91-875d-5b1502403055 X-Archives-Hash: 4741b7590691efc9896eb6a1bfbb39e4 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 09, 2012 at 11:03:48AM -0500, Rich Freeman wrote: > On Fri, Nov 9, 2012 at 10:32 AM, William Hubbs wrot= e: > > That has been done already by toolchain a while back. Take a look at the > > code in toolchain-funcs.eclass. There are very few platforms where this > > function does anything at all these days. It would just be a matter of > > removing linux from the platforms it supports. >=20 > My concern isn't that the code won't do what you're expecting it to. > I have every confidence that the files will move to exactly where you > want them to go. >=20 > My concern is all the downstream effects after that. Does anything > hard-code a path in /? Do any config files in /etc reference those > paths, maybe for plugins/etc? What about linking - will we have any > issues if core system binaries are linked to paths in /? After separate /usr is implemented, I would throw out the patch to -dev to disable this, then people could apply the patch and start testing; this is when we would get all of these answers. > > Since applying the patch itself will not force any rebuilds, it should > > just end up being a natural migration; as things are rebuilt the > > libraries will move from /lib to /usr/lib with no harm being done. >=20 > Except to anything that depends on those libraries being in /lib. > Maybe that is nothing, but until you test the migration you don't > know. =20 See above. You could apply the patch then see what breaks before we actually put it in the tree. > Testing doesn't mean changing the eclass, installing bzip2, and noting > that the library moves to /usr. It means then testing anything that > depends on bzip2 and making sure that they weren't broken as a result. =20 The linker script would stay in /usr/lib and the library would stay in /lib until bzip2 was rebuilt. At that point, the library itself would move back to /usr/lib, so wouldn't that cover linking issues? > Oh, and if everything doesn't move overnight then packages could > migrate in almost any order, which means you have to look out for > potential race conditions. =20 The only way to force everything to move overnight would be to tell everyone to rebuild their systems, which isn't really practical, because we can't make that happen. > I would hope that the main issue is going to be linking and perhaps > @preserved-libs would help with that if it ever becomes stable. > However, when moving so many libraries you need to think carefully > about testing. How many things depend on zlib or ncurses or libcap or > pam or libpcre? I'm not sure how we would break linking, since the linker scripts in /usr/lib would be replaced by the libraries only after each package is rebuilt. The other option could be to remove the calls to gen_usr_ldscript from each linux-only ebuild before we disable it on linux. That way we could see how much things break. Then, once it is out of the linux-only ebuilds, we could disable it on linux. I'm not sure how much that would help though since it would still hit all of the shared ebuilds at once. I definitely do not think that gen_usr_ldscript belongs in this council vote; I"m not even sure it does belong in a council vote, because the details of making this happen would be worked out on -dev. William --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlCdNv0ACgkQblQW9DDEZTjengCeIADCUpsKDW6v3jQ6Kru7GNSz pXEAnAyjf4LniMrkSQ2edi6qtJS8OCJI =FwcU -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH--