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 C6BCA59CAF for ; Thu, 7 Apr 2016 14:41:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C35D921C027; Thu, 7 Apr 2016 14:40:52 +0000 (UTC) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E5AD921C020 for ; Thu, 7 Apr 2016 14:40:51 +0000 (UTC) Received: by mail-oi0-f52.google.com with SMTP id y204so101242107oie.3 for ; Thu, 07 Apr 2016 07:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:sender:date:from:to:subject:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=PQg3Y8WRJp6jKGRxK5EYTAV8VBEuiBrZVSbFVYs/jqY=; b=gqlfi8kQle6goTU+Q+p3Erg3VRz7onW1EWQbzPha4xYJKNMWChZF/b9qWLXNUP3NyH 5q7zTidS/xf7+f2N7Osqh7OJQenCGO4vPb2KXiA8zYOPR5KPvDOgdU/iT/JCiP6cHx/g 25Cu9qzh4GF4nTJYKSxHWwe0sWpi9aAlmnSkTFaWWq8ntB/euwtu0bqYWWa3tnRTegVk qRqgQ9KkFKZ57tWemtkTJVae3gyWRR4QqDoY9DDjWJFW+gMSWIachFX/1+QeZVZ4toI8 v0TcfgzZguGgEzS2txCGcNg4bO0j5BArDmuZWWQGsWpFtqpZYDZSaStfwjjdWqmszGDq Hk3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:sender:date:from:to:subject :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=PQg3Y8WRJp6jKGRxK5EYTAV8VBEuiBrZVSbFVYs/jqY=; b=IorPQh53/fDAkFHyfRYOpIhSsUEaQqBTHdIEqgnq1nocTVc8qRBSOG0Pmo9qk4PdGj 4/u6eOUbjaxlD3W3UCGbIeZS5NfDYcU5LQEF4Zidt5YvNYhqw0es92XZ/xy5z61muZWO PtWqn3Lm7ghl8oc12vohKjUQUjuq2GGS3x9K8wOuP5ztXRwmdFSLqKoB1jKueMFRVboD 5yujIvR1tMQYHG4NmUoLup6nd2lDD0xAd4xOqCk64Xw6hxCrh5Ami0DEba1uic4pgOi4 Hv/BAToQZ9HtRjqec6UJI1hi02Zx4um6boYRBabokHARn5mufbUUcHm54jWhUJC5rA5t Tk1A== X-Gm-Message-State: AD7BkJIIBjNM206/Jd8w34Ge+/ZRKCYYgoVSz9RnVqbKf+Z0qKdmNZSoP3gbgppASIcLcA== X-Received: by 10.157.7.23 with SMTP id 23mr1684136ote.192.1460040050945; Thu, 07 Apr 2016 07:40:50 -0700 (PDT) Received: from linux1 (cpe-66-68-34-247.austin.res.rr.com. [66.68.34.247]) by smtp.gmail.com with ESMTPSA id b70sm2457046oig.12.2016.04.07.07.40.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Apr 2016 07:40:50 -0700 (PDT) Message-ID: <57067172.49cbca0a.693b1.ffff9909@mx.google.com> X-Google-Original-Message-ID: <20160407144049.GA29904@linux1.gaikai.biz,> Sender: William Hubbs Received: (nullmailer pid 30602 invoked by uid 1000); Thu, 07 Apr 2016 14:40:49 -0000 Date: Thu, 7 Apr 2016 09:40:49 -0500 From: William Hubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] usr merge Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <570312c8.1469ca0a.30985.5db1@mx.google.com> <570523FD.3040703@iee.org> <570530D4.4030803@gentoo.org> <20160406204310.GA11167@whubbs1.gaikai.biz> <763f78cb-66f7-484f-bb64-a182f2747d54@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline In-Reply-To: <763f78cb-66f7-484f-bb64-a182f2747d54@gentoo.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Archives-Salt: 8fcf6d88-942f-4a4a-8d36-cb2fcef47b8b X-Archives-Hash: 3061c0f1762835de0c8374b8fe07f16a --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 07, 2016 at 11:12:13AM +0200, Alexis Ballier wrote: > On Wednesday, April 6, 2016 11:36:09 PM CEST, Richard Yao wrote: > > As for those benefits, they do little for {/usr,}/sbin vs=20 > > {/usr,}/bin, which is where the incompatibilities tend to live.=20 > > I encountered one of these in powertop the other day (patch=20 > > pending). The benefits of being able to access things from both=20 > > places are somewhat exaggerated given that compatibility among=20 > > systems has long required searching $PATH and likely always=20 > > will. >=20 > PATH is a shell thing; some libc functions like execvp duplicate this=20 > functionality but that's all; you dont have PATH in shebangs nor in execv. >=20 > >> Note, we are not > >> talking about squashing /usr out of the equasion, but merging /bin, > >> /sbin and /lib* into their counterparts in /usr and creating symlinks = in > >> the root directory pointing to the counterparts in /usr. > > > > While one guy did the reverse (and the reverse ought to be okay=20 > > for those that want to do that), no one appears to think that=20 > > adopting the reverse is what is being suggested. Having this=20 > > sort of clarity on whether forcing this on everyone via=20 > > baselayout update, just providing the option for those who want=20 > > it or some combination of the two (e.g. a long transition period=20 > > in which both are supported) is being discussed would be nice=20 > > though. This is not a Boolean decision. >=20 > I've been under the impression since the beginning of the thread that it = is=20 > what is being proposed: make it possible but support both. We can't force= =20 > usr-merge without battle testing the migration process anyway, which mean= s=20 > there needs to be such a long transition period. I do agree that we need a testing period to iron out the migration process. Like I said, I'm not quite comfortable even with running it here because I don't know if it will break my system, and once you do the migration, the only way to undo it is to wipe and re-install. I have thought about a way to roll back, but I don't see that as very feesable, so once you migrate to a /usr merged setup, there is no way to undo it. Also, the usr merge affects linux only; we aren't talking about messing with *bsd. After the testing period is over, I'm confused about why we should support both layouts. With separate usr without initramfs gone, the usr merge is transparent to end users because of the symbolic links in /, so there should be no reason to keep supporting both layouts once we are satisfied with the migration process. William --ZPt4rx8FFjLCG7dd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlcGcWwACgkQblQW9DDEZThk4wCeJiFnm71w6h9cImjq/hEK8EMu OQEAnjP3dUsHI/2XxMHVDIVMxjnxkn7J =04Xq -----END PGP SIGNATURE----- --ZPt4rx8FFjLCG7dd--