From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-project+bounces-2230-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 677DA1381F3
for <garchives@archives.gentoo.org>; 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 <garchives@archives.gentoo.org>; 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 <gentoo-project@lists.gentoo.org>; Fri, 9 Nov 2012 17:01:54 +0000 (UTC)
Received: by mail-oa0-f53.google.com with SMTP id j6so4113318oag.40
for <gentoo-project@lists.gentoo.org>; 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 <w.d.hubbs@gmail.com>
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 <williamh@gentoo.org>
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>
<CAGfcS_=s51=hL9VQvdDJWO_ZMnS1kkb8n_YRxLPuqSX_herY=A@mail.gmail.com>
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="ReaqsoxgOBHFXBhH"
Content-Disposition: inline
In-Reply-To: <CAGfcS_=s51=hL9VQvdDJWO_ZMnS1kkb8n_YRxLPuqSX_herY=A@mail.gmail.com>
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 <williamh@gentoo.org> 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--