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 EB16E59CAF for ; Tue, 5 Apr 2016 10:11:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 678C821C025; Tue, 5 Apr 2016 10:10:58 +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 7AA2921C006 for ; Tue, 5 Apr 2016 10:10:57 +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 CEE8E340C72 for ; Tue, 5 Apr 2016 10:10:55 +0000 (UTC) From: Alexis Ballier To: Subject: Re: [gentoo-dev] usr merge Date: Tue, 05 Apr 2016 12:10:51 +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: <18fd62cb-8bb8-40d9-99a1-fe078c221f66@gentoo.org> In-Reply-To: <570312c8.1469ca0a.30985.5db1@mx.google.com> 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: 123378b7-26ad-495f-a042-9087a750b3ee X-Archives-Hash: 9214347e6a049c14de1eed229dac1f06 On Tuesday, April 5, 2016 3:19:59 AM CEST, William Hubbs wrote: [...] > 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 (OT: maybe it'd be a good oportunity to kill SYMLINK_LIB too :p) > /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 think that prior to that we have to ensure that packages with intra=20 collisions are not merged: What happens with current coreutils ebuilds that=20= install, e.g., /bin/seq and a /usr/bin/seq symlink to it ? I haven't looked at the actual code, thus I can only assume there are no=20 guarantees, which is definitely bad. > 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. Does it behave properly wrt portage's way of tracking of package files? I=20 remember that modifying files owned by portage used to cause issues. What should baselayout ebuild do on systems that have not run that script ? Also, I think your script may not work: # copy binaries for dir in /bin /sbin /usr/sbin; do =09run_command cp -a $dir/* /usr/bin done ---> Here it is important to ensure nothing /usr/bin/ is a symlink to /bin,=20= otherwise this would just copy, e.g., /bin/seq onto /bin/seq # Create the /usr merge compatibility symlinks for dir in /bin /sbin; do run_command rm -rf $dir ---> where are the 'ln' and 'rm' taken from after this step ? If this fails here, you're also leaving the system in a broken state. run_command ln -s usr/bin $dir done