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 1752D59CAF for ; Wed, 6 Apr 2016 07:42:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3FEE321C057; Wed, 6 Apr 2016 07:42:12 +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 19B3421C020 for ; Wed, 6 Apr 2016 07:42:10 +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 73DB2340B63 for ; Wed, 6 Apr 2016 07:42:09 +0000 (UTC) From: Alexis Ballier To: Subject: Re: [gentoo-dev] usr merge Date: Wed, 06 Apr 2016 09:42:04 +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: <674824c3-71f2-4ebd-bb4b-fa70b26b0669@gentoo.org> In-Reply-To: References: <570312c8.1469ca0a.30985.5db1@mx.google.com> 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: 4d0ac86f-ff5e-4fc9-b294-2c787073742b X-Archives-Hash: 6d2a8a40acbb4a7e674b1171400876d3 On Wednesday, April 6, 2016 6:15:58 AM CEST, Richard Yao wrote: >> On Apr 4, 2016, at 9:19 PM, William Hubbs wrote: >>=20 >> All, >>=20 >> 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. ... > > Here are the violations: > > http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#binEssentialUserCo= mmandBinaries > > http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#sbinSystemBinaries= > > http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#libEssentialShared= LibrariesAndKern > well, those are not violations: fhs mandates a certain set of binaries in=20 those paths; this is still the case with a usr-merged system. i thought the symlinks would be a problem, but fhs states: > The following directories, or symbolic links to directories, are required i= n /. so, really, i dont see any violation there >> 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: >>=20 >> /bin->usr/bin >> /lib->usr/lib ... > > We will have users whose system configurations rely on the FHS=20 > complain about us breaking boot if we force this. i dont think anybody is talking about forcing this >> I put some thought also in how to nigrate live systems, and I'm not sure >> 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. >>=20 >> The script is attached. >>=20 >>=20 >> Thoughts on any of this? > > > This was invented in Solaris and copied by RHEL. The upgrade=20 > path for the /usr merge on those systems is a complete=20 > reinstall. Upgrading from RHEL6 to RHEL7 this Solaris 10 to=20 > Solaris 11 is not supported. The reason being that there are=20 > ways of configuring the system boot process with the original=20 > layout that break if you try using scripts to migrate to the new=20 > one. A USE flag for the /usr merge that is off by default would=20 > allow us to have both worlds without putting any systems at=20 > risk. that's what i'm actually more worried about: the fact they failed to have a=20= proper upgrade path doesnt mean it is impossible, just that it is not easy. only being able to propose usr-merge for new installs makes it useless for=20= gentoo imho: i, for once, use only 1 gentoo install for the lifetime of my=20= / disk... note that being able to properly migrate is a *requirement* for having it=20 as a useflag > If others are not willing to be advocates for those users that=20 > would only make themselves known after an a fundamental change=20 > has been made and people are determined to go ahead with this, I=20 > suggest having and testing a plan for backing out the change=20 > should the backlash from users after systems break be more than=20 > people can stomach. This is not the sort of change we should=20 > make without an "exit strategy". ironing out that kind of strategy is the point of this thread :) Alexis.