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 C98971381F3 for ; Mon, 30 Sep 2013 02:31:17 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 893A3E0D5B; Mon, 30 Sep 2013 02:31:13 +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 8940AE0ADF for ; Mon, 30 Sep 2013 02:31:12 +0000 (UTC) Received: from 118.70-40-235.netnet.net ([70.40.235.118]:44359 helo=[192.168.1.144]) by mahal.bihira.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1VQTGP-0004Fx-0E for gentoo-user@lists.gentoo.org; Mon, 30 Sep 2013 02:31:10 +0000 Message-ID: <5248E26D.7090601@sporkbox.us> Date: Sun, 29 Sep 2013 21:31:09 -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> <5248D265.4080908@sporkbox.us> <5248DB6D.50903@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: 1988eb95-03c9-495a-be32-f9b6279c4fbd X-Archives-Hash: cf5abacbd8c8211d9456d2ed0d720a8c On 09/29/2013 09:25 PM, Mark David Dumlao wrote: > On Mon, Sep 30, 2013 at 10:01 AM, Daniel Campbell wrote: >> On 09/29/2013 08:51 PM, Mark David Dumlao wrote: >>> On Mon, Sep 30, 2013 at 9:22 AM, Daniel Campbell wrote: >>>> It's fairly obvious (to me, anyway) that anything mounting a filesystem >>>> and making it available is system-critical. I run samba and don't need >>>> it for boot, but like you said, someone may need that. I wouldn't see a >>>> problem with smbmount being in /bin. FUSE deserves similar treatment. >>>> LVM's another that probably deserves special treatment. >>>> >>> >>> If you allow FUSE you've already failed, because arbitrary programs can >>> be required by FUSE filesystems. Suddenly your ssh client should be pushed >>> to /, or your telnet, or rsync, or ftp. >>> >> FUSE is that lenient with what it can use to mount with? o_O > > Fuse is filesystems in userspace. The hard problem that isn't obvious > here, is that > anybody can come up with a userspace filesystem, and there is ZERO intelligence > in the package manager that some filesystem is dependent on some userspace > logic. > > for example, there's a filesystem called sshfs. It allows you to view an ssh > connection as a directory. sshfs itself could be in /, but it depends > on ssh and its > libraries, which are normally in /usr. Now what do you do? Just to > support sshfs, > you have to move or copy all those programs to /. Portage doesn't know this. > Ebuilds don't know this. Manual compiles don't know this. What should the ssh > packagers do? What should the fuse-sshfs packagers do? What should users > who are manually rolling out sshfs do? > > How about when you develop the next revolutionary crazy filesystem that > allows you to view emacs sessions as directories? What should the emacs > packagers do? What should the fuse-emacsfs packagers do? What should users > manually rolling out that do? > > You want to automatically version /etc using some filesystem that uses a git > backend (I'll call it gitfs). What should git packagers do? What > should fuse-gitfs > packagers do? etc.... How about svnfs? hgfs? bzrfs? scpfs? ... > Ah, I wasn't aware of how flexible and arbitrary fuse could be. In that case I'd probably keep it out of /bin for the reasons you outlined. But that doesn't solve the problem of "what if people want to boot with fuse?". At least, not without an initramfs. And then we've created a similar problem. If the proposed solution is all binaries and libraries in the same root/prefix directory, then why call it /usr? It has little to do with users if it's nothing but binaries, libraries, etc. In addition, would a local directory still be under this, for user-compiled programs not maintained by the PM? Or does that deserve a different top level directory? Then there's /opt, whose purpose I'm still not sure of. This is strengthening the idea that something new should be thought up and drafted. Not necessarily by us at Gentoo, but *somebody*. If I was crazy and knowledgeable enough I'd volunteer myself.