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 C64CC59CAF for ; Thu, 7 Apr 2016 09:12:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7D0E9E089E; Thu, 7 Apr 2016 09:12:19 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 7CF46E086F for ; Thu, 7 Apr 2016 09:12:18 +0000 (UTC) Received: from localhost (dra13-4-78-234-166-189.fbx.proxad.net [78.234.166.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 7B5AC340E06 for ; Thu, 7 Apr 2016 09:12:17 +0000 (UTC) From: Alexis Ballier To: Subject: Re: [gentoo-dev] usr merge Date: Thu, 07 Apr 2016 11:12:13 +0200 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 Message-ID: <763f78cb-66f7-484f-bb64-a182f2747d54@gentoo.org> In-Reply-To: References: <570312c8.1469ca0a.30985.5db1@mx.google.com> <570523FD.3040703@iee.org> <570530D4.4030803@gentoo.org> <20160406204310.GA11167@whubbs1.gaikai.biz> Organization: Gentoo User-Agent: Trojita/0.6; Qt/5.5.1; xcb; Linux; Gentoo Base System release 2.2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 9c294d6c-d247-4d87-af92-35709d9d88bb X-Archives-Hash: c2e089c60dfefb5e3ffc1b14547bfdcb 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. 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. >> 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. 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 means=20= there needs to be such a long transition period. Alexis.