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 CB5A059CAF for ; Wed, 6 Apr 2016 14:58:18 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2FAB021C0A5; Wed, 6 Apr 2016 14:58:11 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (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 DC93A21C088 for ; Wed, 6 Apr 2016 14:58:08 +0000 (UTC) Received: from [192.168.1.178] ([84.92.211.151]) by mrelayeu.kundenserver.de (mreue101) with ESMTPSA (Nemesis) id 0LyV78-1brSKv1oPe-015tfg for ; Wed, 06 Apr 2016 16:58:07 +0200 Subject: Re: [gentoo-dev] usr merge To: gentoo-dev@lists.gentoo.org References: <570312c8.1469ca0a.30985.5db1@mx.google.com> From: "M. J. Everitt" Message-ID: <570523FD.3040703@iee.org> Date: Wed, 6 Apr 2016 15:58:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 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 In-Reply-To: <570312c8.1469ca0a.30985.5db1@mx.google.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OaQiNNOK9IST6jkQRvsV9jRCdnC4Fu44P" X-Provags-ID: V03:K0:bC2oBQo30nDWNo5ubk2XpmiC50pWJksOpGi2gomt+rrRL/7M0x0 4cx2ZP0SytkpTpcxOYE7yEH2yO6ngC9FQxda09/UBTjiFNJ6F4VzwyZ6vIcwRVyErDJCCUj iLNMSrvgbU+RT/df50q6mSQFcxujX0hFxbIYh/KGCJB0lmy0bvUgeCSQW5sUj5WzWZlICGV frawNMj1mEOi/+Upwilvw== X-UI-Out-Filterresults: notjunk:1;V01:K0:zpdjByFjLOQ=:nbZmngVHrz1oPQe0M8QrE2 ufEmM9b40V1D/Denh/gDsfE/LjZ6HsO3nclRNirrIXZTi6aJG1toMCaHX+z79kEzRLYROeKUI 4ICdQmthlTCYp2fHXhvWX3QpGpCrcRvqNuhwkt1Uan1iuLsy0TvnqNh29VA1fKN3sxAlLvHpw qutyEd4B/7VvAkuLHzHp+d5LLLvDctw+BTIBkRNwDwi2P2L7L/vEBgiklvJ7nui7wWya55CEa 81ztbT2q0J/m9N6HmELX4nZi7fouJIu8LV9mzvFU1PQdrpbTY6VoFF/deL6Qt1/C0nxonb79k 2LURJzNOV9WOu6eSVbuGXH4wcfVIK/TVpRrSNNTYGHgeqqpPqjZxwkiVyp0pRVGl30QpZo+cT LGnzjD4pAA36PWCobQ6AvYEsFvkR8gAMwpXAzwjOmlfNrnrdpDgw7ebGxH6/3WHZsmj3lxugr wd9aiBpYqiUlBbbnveMBicf4YRgmMYSl7HZ29H3sJwLeuKn8WsTU8lD1RGRRJJIV3AH6eB5ys 36CEH85XxJwgyU4ZorlhFGlO6k9bRQ/vUtQ/v7wnnKjSXdp8gAHX3Pq92eKaeMgORg7TEDsFY flPzEql8LnERmILsquiwtzCxFWCxleDgWbg+014BohCAsSscJ5d99af2IOBzrZI/GOhVPI1oI yYT4nzu7s/GpplKminZyR78DXRZzEm5cdv3Cly7kEwgsYbLB/SVyintutv7nglHONByY= X-Archives-Salt: 719ffb84-de0b-40f9-9231-32e0393271a2 X-Archives-Hash: 9eb018d12534954b0118ad4fe4c5c1d6 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OaQiNNOK9IST6jkQRvsV9jRCdnC4Fu44P Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable What, if any, is the benefit of squashing /usr out of the equation? I happen to have a few workstations that load their /usr off an NFS share presently, with some bodgery-workarounds I did pre the udev notification about initramfs's which I have never got around to implementing (although I'm pretty sure I have the tools now to do, along with UUIDs for boot media). Whilst these aren't currently scheduled for upgrade, I don't personally see any merit, given discussions here about work needed to 'shore up' a change to match some particular use case. I would therefore definitely agree with those that have proposed that this is an Option and not a standard gentoo install item unless there are some specific caveats that this solves. Michael/veremit. On 05/04/16 02:19, William Hubbs wrote: > All, > > I thought that since the usr merge is coming up again, and since I lost= > track of the message where it was brought up, I would open a > new thread to discuss it. > > When it came up before, some were saying that the /usr merge violates > the fhs. I don't remember the specifics of what the claim was at the > time, (I'm sure someone will point it out if it is still a concern). > > I don't think creating usr merged stages would be that difficult. I > think it would just be a matter of creating a new version of baselayout= > that puts these symlinks in place: > > /bin->usr/bin > /lib->usr/lib > /lib32->usr/lib32 > /lib64->usr/lib64 > /sbin->usr/bin > /usr/sbin->bin > > Once that is in place in a new baselayout, I think portage's colission > detection would be able to catch files that had the same names and were= > originally in different paths when building the new stages. > > I put some thought also in how to nigrate live systems, and I'm not sur= e > what the best way to do that is. I wrote a script, which would do it in= > theory, but I haven't tested because I only have one system and if > it breaks it the only way back would be to reinstall. > > The script is attached. > > > Thoughts on any of this? > > William > --OaQiNNOK9IST6jkQRvsV9jRCdnC4Fu44P Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXBSP+AAoJEEwwM0+TwiNxVAMP/08/NcDCplNajPeKI/wOAfVt I63NuMmrPbcmoUsKE5SeB29Sovm4I5mj8N4XfYwvprZ5tPQsMiyrXLEGiloGUk8t KWg3sOveqaNat7a8r7+509ffmYl60kZpom65k9eOcf4uWPY8lGjBS+ol+YBdaPRL NB/KaBnsOywzl3HkFERxAilLZoEiuvsO0S5CBN7gJ1/pePYZ0vjuM4by6GbwBPV6 5ItW1YtTk6cYN+KEX3u3nczjOb2gBJAv1D1MjJOlFODvQFX0t9hrCju9bbgD/dkP 42jj7gUKRKRUlBw15CyzQ9+EL9l0iAWbLc/RCQsgzUf043nd/Me/I5OxoVHHDZTk pDFCmTdz0p4OmCsXOLMPsoZhj7CwPx8R1LaCvoTC8h2wj4z2sPjmHQugMFs9Wcun NjjbshaI4ugJJnhNPpsoZC0EU403SynLAhtXqGSQBBnd+NE2DfVzZu6nfzp6W9bS 6ABv78AuNBoUHRA4GuIyehPg1b6SaWYiLO4cnSJm6zP2J2kB5dZRer6fT9lVnzWl I+g75R/I7/d+RW1ibweQ71WRD9BmLazZMvqs8LuhVuFqD5e9UFFZFvWZswCiRlm8 v0Z7kusuYLD1HbiLT11QII+s/cPbFwrDf03EIhyGyRDnHB9uRqTb7PsPRNQKcfqC P/p7ri2j+7kHiiGnTg2u =/jI8 -----END PGP SIGNATURE----- --OaQiNNOK9IST6jkQRvsV9jRCdnC4Fu44P--