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 A462C59CAF for ; Sun, 10 Apr 2016 11:56:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5372A21C07E; Sun, 10 Apr 2016 11:55:59 +0000 (UTC) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [69.252.207.43]) (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 323A221C032 for ; Sun, 10 Apr 2016 11:55:58 +0000 (UTC) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by comcast with SMTP id pDy3a8vrVjuYRpDy9aiPzP; Sun, 10 Apr 2016 11:55:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460289357; bh=602SZoBoH5NOW1Y9pJ9JYnzMGrOq2n7wo3/QpjnZk/g=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ABK6KNFcLYaKWRM/DSJqvCa7JW7tGCaeiP1WQkrx7gHKG0c1BlVehfbqO5jARRp8Y nSALkHEqAJolWzT8ueASJmeFkNQxenjKe330C80iF8V+OYoDziMxA7wx705zsrsM38 RT1ldhnTkV4QvZOc9kQtayRXRm5snAzXfCC8LrSC0dtIjbs1Eta9f/gywfe9ni8TO8 epkdO40y6Y5MHzn6oDwWz7n/2P/MYwkXbTOK6vd3+Kp5uUM/n1mLjoHsQeEcWPPlYI 10wZDjC3Wv2E+yMmeV9563fQLP9S2Wh9PuN6v5gD7kCAcO6Wy99yoxtnIoBdlXFyxA lFXEN0IF6xt4A== Received: from [192.168.1.13] ([76.106.83.43]) by resomta-ch2-12v.sys.comcast.net with comcast id gbvw1s0090w5D3801bvwTF; Sun, 10 Apr 2016 11:55:57 +0000 Subject: Re: [gentoo-dev] usr merge To: gentoo-dev@lists.gentoo.org References: <570312c8.1469ca0a.30985.5db1@mx.google.com> From: Joshua Kinard Message-ID: <570A3F35.6080405@gentoo.org> Date: Sun, 10 Apr 2016 07:55:33 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Thunderbird/44.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: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Archives-Salt: dbc64c40-ee99-4e26-a8f1-51fa82bb96aa X-Archives-Hash: d48db007450e6f6adb604fbcbfa5b0b2 On 04/04/2016 21: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 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. > > The script is attached. > > > Thoughts on any of this? > > William I looked at Thunderbird, at my folder labeled "gentoo-dev", and it had "666" unread messages. I should've done the smart thing and closed my mail program. But noooo, I had to look inside the folder. I am now regretting this decision. *sigh*, I can see the thread has gone clongie 'round the blonger, so all I'll have to say is we should still try to maintain the choice for users. But, in order to evaluate what amount of effort is needed to maintain that choice, we need to know what packages break on such a setup, what the level of effort needed to fix them is, and do those fixes impact the non-split crowd. Create like, a table on the Wiki or some kind of metadata property per-package that can contain a boolean or tri-state flag indicating whether it works or doesn't work (or kinda works) on split-usr. Or a tracker on Bugzie. Something. Once we know this, then we can work out what's the minimum system that can be successfully run on split-usr. Then, knowing *that*, we can see if that system can be supported by our @system target or some minimal subset of @world. As new package versions come out of upstream, we update this metadata with changes to the split-usr status, and this then provides a history of the more or less amount of difficulty needed to maintain support for split-usr, and *then*, we can make an objective decision to continue supporting or not supporting the capability. As for me, I am flat out ruling out a full-reinstall of all my systems. I have fixed disk partition layouts on all of them that cannot be re-arranged unless I tar up each filesystem and temporarily move it off, then rebuild the MD-RAID and reformat the filesystems. I am simply not going to do that on my many SGI systems, and whatever facet of upstream, whether it's some core GNU package or RH itself, can go pound sand for all I care. I'll go back to a static /dev and I'll manually mknod any missing devices if I have to. You know it's getting ridiculous when you can maintain a Windows/NTFS partition layout easier than a Linux one. -- Joshua Kinard Gentoo/MIPS kumba@gentoo.org 6144R/F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic