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 73DF01381F3 for ; Mon, 30 Sep 2013 01:50:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 98C0AE0F30; Mon, 30 Sep 2013 01:50:18 +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 85B88E0EB3 for ; Mon, 30 Sep 2013 01:50:17 +0000 (UTC) Received: from 118.70-40-235.netnet.net ([70.40.235.118]:44021 helo=[192.168.1.144]) by mahal.bihira.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VQSco-0005nH-2u for gentoo-user@lists.gentoo.org; Mon, 30 Sep 2013 01:50:15 +0000 Message-ID: <5248D8D6.8040901@sporkbox.us> Date: Sun, 29 Sep 2013 20:50:14 -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> 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: 7467fe5b-b425-44d3-b3b3-cbb181bbf01a X-Archives-Hash: 69ac6104549aea69cb7ea6fdd26dd0d7 On 09/29/2013 08:40 PM, Mark David Dumlao wrote: > On Mon, Sep 30, 2013 at 8:54 AM, Daniel Campbell wrote: >> I'm not affected by anything regarding the /usr switch, but I'd like >> to have a good talk with the first person who decided a >> system-critical binary belonged in /usr instead of /bin or /sbin. >> They've created a mess for every distro and any project that depends >> on their work. > > (sorry for the previous post, accidentally clicked somewhere onscreen) > > As I've pointed out before: > 1) "system-critical" is actually dependent on the system. A system dependent > on an smb share will find smbmount system critical. One dependent on > zfs-fuse will find fuse system critical. With the advent of fuse, > some filesystem > that depends on an arbitrary user program will find that system-critical. > While this works for for 99.(99?)% of user systems out there, FHS > is supposed > to be targetting all of them, and so it fails in principle in that respect. > I remember making a lengthy thread on this mailing list challenging how FHS > defined this and it appeared that nobody could make a defense. > 2) the reality is, it's not just binaries even. There are some things > that binaries > depend on, that in theory should be in /. For example, the hwid database, or > libraries. Libraries make for a complex problem, because /usr is supposed to > be network-sharable. Any libraries your programs depend on can't simply just > be pushed to /, because then there'd be the chance that the > programs and their > libraries were not in sync. Libraries were one of my concerns when I was replying. I thought to myself, "Well damn, won't shared libraries make this even more difficult?" Perhaps it's a case for static-linked core binaries. :) 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. > > I made a handful of criticisms to FHS in that thread before, and nobody was > able to mount a suitable defense. The point being, even in principle, separating > / and /usr is flaky design at best. That we just so happened to > accumulate a number > of packages that are historically installed to /usr is a consequence > of that. It's not > even necessarily the fault of the upstream developer, who's not > supposed to care so > much which PREFIX they install to, or the distro packager, who can't yet predict > how the user will tailor their system. > > 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