From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1S7xlj-00017F-Ce for garchives@archives.gentoo.org; Wed, 14 Mar 2012 23:38:11 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AE27FE0A93; Wed, 14 Mar 2012 23:38:02 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by pigeon.gentoo.org (Postfix) with ESMTP id 2A4FAE09DF for ; Wed, 14 Mar 2012 23:37:36 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 9D12820C71 for ; Wed, 14 Mar 2012 19:37:36 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute6.internal (MEProxy); Wed, 14 Mar 2012 19:37:36 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=ayl0FYae2KSGxV9YLeMivjDC1vo=; b=f7aC+BC06kDo9GfcnOOmGiowtSfT 1Z+XBv/r12Izo3bNsRRPR32hPAPxBYgCy/l2ffNXcJ5xvmGV2gexfinAaJ64G/sA U/X8kjXVf/O2V0FfPu79FWjp7YbVWRhL1jTJwlbK8U8hNOeedNuIclsShxyWJP5L UYDoWo3vQAZf0qs= X-Sasl-enc: uUmeoxkIRfVw+BJmvCeO7bknSNZVxrrtYxwJYK6T2jFO 1331768256 Received: from localhost (c-76-121-69-168.hsd1.wa.comcast.net [76.121.69.168]) by mail.messagingengine.com (Postfix) with ESMTPSA id 294514825A5; Wed, 14 Mar 2012 19:37:36 -0400 (EDT) Date: Wed, 14 Mar 2012 16:37:34 -0700 From: Greg KH To: Richard Yao Cc: Greg KH , gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Let's redesign the entire filesystem! Message-ID: <20120314233734.GA29474@kroah.com> References: <4F60D585.4050206@gentoo.org> <4F60E9C1.7050600@gentoo.org> <20120314210456.GB11179@kroah.com> <4F611E09.1040602@cs.stonybrook.edu> <20120314224916.GA12279@kroah.com> <4F61294B.9040101@cs.stonybrook.edu> 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F61294B.9040101@cs.stonybrook.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 8d81e041-7aff-4e0a-a5a1-f25d9c15ccc5 X-Archives-Hash: 8998e48379d16fe9876b165f86c4fa70 On Wed, Mar 14, 2012 at 07:27:07PM -0400, Richard Yao wrote: > >> 3. Why not let the users choose where these directories go and support > >> both locations? > > > > Because a plethera of options is a sure way to make sure that half of > > them don't work over the long run. > > > > We aren't Debian here people, we don't support "everything" :) > > Gentoo provides far more options than Debian does, so this seems > somewhat contradictory to me. Not really, I don't think we support systems without udev anymore, right? And we get away with a lot of these different "options" at compile time, which makes it easier than what Debian has to handle, so perhaps it's not a fair comparison. > > If you want to support both, great, feel free to step up and do the > > work. > > Fair enough, however, I should remind you that not much will happen > without a decision from the Gentoo Council. I am willing to accept > whatever decision they make, but I think that exposing this decision to > users is something that is within our ability to do. I didn't think the Council ruled on technical questions. In fact, how is this relevant at all anyway? It's quite simple in that we don't support systems today with a separate /usr/ without a initramfs/initrd. If it happens to work, wonderful, but don't expect Gentoo developers to rewrite the upstream packages to work for this type of unsupported systems, it's not going to happen. Or are you referring to the "no more /bin and /sbin" thing? That's just going to happen "naturally", one day in a few months or years, your system will have moved to this without you even realizing it :) > Portage provides use with the ability to do abstractions that other > distributions cannot do, such as permitting people to merge > /usr{bin,lib{32,64,},sbin} into /. Sure, but that doesn't mean that the packages that are being merged will actually work :) greg k-h