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 6D2571381F3 for ; Mon, 30 Sep 2013 02:15:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B0863E0BFB; Mon, 30 Sep 2013 02:15:46 +0000 (UTC) Received: from mahal.bihira.com (mahal.bihira.com [67.159.5.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id B2D2EE0BF0 for ; Mon, 30 Sep 2013 02:15:45 +0000 (UTC) Received: from 118.70-40-235.netnet.net ([70.40.235.118]:44196 helo=[192.168.1.144]) by mahal.bihira.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VQT1S-0001Uf-I0 for gentoo-user@lists.gentoo.org; Mon, 30 Sep 2013 02:15:43 +0000 Message-ID: <5248DECF.7050408@sporkbox.us> Date: Sun, 29 Sep 2013 21:15:43 -0500 From: Daniel Campbell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130921 Thunderbird/17.0.9 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] systemd installation location References: <20130929195206.GA16744@linux1> <5248CBB9.5010205@sporkbox.us> <5248D8D6.8040901@sporkbox.us> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mahal.bihira.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sporkbox.us X-Get-Message-Sender-Via: mahal.bihira.com: authenticated_id: lists@sporkbox.us X-Source: X-Source-Args: X-Source-Dir: X-Archives-Salt: fd50f4e1-6951-47c1-8a03-46847f5a6043 X-Archives-Hash: 13705fb70c4a5d7107f03ed021126989 On 09/29/2013 09:05 PM, Mark David Dumlao wrote: > On Mon, Sep 30, 2013 at 9:50 AM, Daniel Campbell wrote: >> Anyway, I'm not in favor of FHS _per se_, but it sounds pretty >> reasonable to have some semblance of order among where different parts >> of a system go. Shoving everything into /usr and symlinking everything >> else seems like a stop-gap or good-enough solution that came about due >> to ignoring the existing standard (FHS) and refusing to try to change >> it. I could be wrong, though. My point is I'm not dogmatic about it; I >> just think that if the FOSS community were willing, a better solution >> could be crafted. > > It's true that it's nice to have a semblance of order where different parts go. > But "all libraries and binaries in /usr" is also a semblance of order. You don't > separate stuff for the sake of separating stuff. You separate them because you > have a good reason to separate them. It turns out that there isn't a good reason > to separate them, and that there's no way to predictably separate them. > > Mushing them together isn't just a stop-gap or good-enough solution. The > idea of keeping system-critical separate from non-critical was not maintainable > in the long run to begin with. > If separating them was unmaintainable, why bother with /bin and /sbin at all, then? If /usr is essentially replacing what / was originally, it's hard to take any filesystem standard seriously and we return to chaos. What was /usr's original purpose? I'm not really in favor of the separation or the merging; I'm in favor of what makes sense. For now, shoving things into /usr is practical because most other software does it. But that's following a trend. It's become *de facto* standard instead of a well-designed, well-reasoned standard. If the change to /usr was brought about because the FHS has holes in it, why not draft a new FHS completely from the ground up? Sometimes a vast rewrite is necessary in a standard, and the new standard could address modern challenges. >>> If you were in the shoes of the ebuild packagers, you would be hard-pressed to >>> predict which packages belong in the / PREFIX and which ones in /usr PREFIX, >>> 100 times out of 100. But you need 100 times out of 100 or you'll get >>> people whining >>> that they can't boot or whining that they need to do some migration. That's >>> why / and /usr separation is broken. >>> >> I agree, but perhaps the / and /usr separation is a symptom of a greater >> problem instead of being the problem in and of itself. Like Inception, >> maybe we need to go further. :P > > The greater problem is what I'm pointing out already. Even in principle, you > just can't predict which files belong in /. It's always been a case-by-case, > system-by-system thing, and it just so happens that 99.9xxx% of the cases > are the same. Distro packagers, however, have to decide for 100% of the cases. > So they're going to end up making weird decisions that are easy for you to > second-guess but are actually tough. > > If you want to solve the "hard problem", you want to create a tool that > will automate / and /usr migrations. Portage has to be aware of the tool > and maybe 100% of ebuilds will have to be rewritten to take advantage of the > dynamic prefixes set by the tool. That solves it for good, and you can have > your / and /usr separate. But only for gentoo. > > Every package manager needs to have a similar tool and similar intelligence > for that to work. > I agree, but I don't see a tool like that coming up. Enforcing a /usr merge and in edge cases forcing initramfs is the right *practical* solution, but I don't think it solves the greater problem, which is social and organizational. It may not even be a solvable problem, given how vast and diverse the FOSS world is. But maybe discussion on it can still be insightful, even if it can't be fruitful.