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 240511381F3 for ; Sun, 11 Aug 2013 14:59:45 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 99195E0B35; Sun, 11 Aug 2013 14:59:44 +0000 (UTC) Received: from a1www.kph.uni-mainz.de (a1www.kph.uni-mainz.de [134.93.134.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7CAF7E0AB7 for ; Sun, 11 Aug 2013 14:59:43 +0000 (UTC) Received: from a1i15.kph.uni-mainz.de (a1i15.kph.uni-mainz.de [134.93.134.92]) by a1www.kph.uni-mainz.de (8.14.4/8.13.4) with ESMTP id r7BExfnw001378 for ; Sun, 11 Aug 2013 16:59:41 +0200 Received: from a1i15.kph.uni-mainz.de (localhost [127.0.0.1]) by a1i15.kph.uni-mainz.de (8.14.6/8.14.2) with ESMTP id r7BExeMr001267; Sun, 11 Aug 2013 16:59:40 +0200 Received: (from ulm@localhost) by a1i15.kph.uni-mainz.de (8.14.6/8.14.6/Submit) id r7BExbhs001263; Sun, 11 Aug 2013 16:59:37 +0200 Message-ID: <20999.42712.964581.102162@a1i15.kph.uni-mainz.de> Date: Sun, 11 Aug 2013 16:59:36 +0200 To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Support for separate /usr In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64-pc-linux-gnu) From: Ulrich Mueller Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="pgp+signed+wfAIEJJNmqYwMbh"; micalg=pgp-sha256; protocol="application/pgp-signature" X-Archives-Salt: 2081c041-6b5b-4e30-9803-3c9de1d7d479 X-Archives-Hash: fc187bcf98f85a985d470f6d08ab7a88 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --pgp+signed+wfAIEJJNmqYwMbh Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >>>>> On Thu, 1 Aug 2013, Rich Freeman wrote: > On Thu, Aug 1, 2013 at 4:04 PM, Alexis Ballier > wrote: >> I have no opinion whether separate usr should be supported or not: >> I have not been using this layout since years. However, I strongly >> prefer some kind of consistency: The traditional layout with a >> minimal / to boot or the usr move both have their advantages; if we >> go for something in between we get none of them. > I tend to loosely agree here. > My inclination right now is to support this proposal if either of > the following is true: > 1. Somebody explains that right now the absence of a decision is > causing them actual problems (extra work, limitations, whatever). > 2. This becomes necessary to enable some larger long-term goal, > which has received council approval. > #2 was basically covered by Alexis already. > Regarding #1, I informally emailed the base-system maintainers a > week ago about whether there was any need to revisit last year's > decision. I didn't really get a sense that anybody really needed the > council to step in now. I recognize that William is also a > base-system maintainer so if he wants to state that he is subject to > some kind of extra work or such supporting separate /usr without an > early boot workaround I'll certainly be sympathetic. > I do favor the dropping of support for separate /usr without an > early boot workaround. I just don't think the council should > actually step in until somebody needs us to, or as part of some > larger plan. If the base-system maintainers have things under > control, better to let them handle it. I mostly agree with aballier and rich0. It so happened that I had chaired the 2012-04 council meeting and it seems that I failed to make sure that the vote was on a well-defined question. Trying to interpret or clarify that 2012-04 vote won't help much: That a separate /usr _with_ an initramfs is supported is self-evident, so it would have been moot to vote on this. OTOH, a separate /usr being supported _without_ an initramfs raises the question what "supported" means. Obviously there are situations where such a configuration doesn't currently work, and it is not even clear if making it work would be feasible. For example, if a user chooses to emerge sys-apps/shadow with cracklib and pam USE flags enabled, then he cannot expect it to be fully functional without /usr being mounted. So there _is_ some amount of inconsistency already, and maybe it's not even fixable, given the many possible configurations with different USE flags. (For a binary distro, it may be easier.) However, for basic configurations, like the one used for stage3, the root file system still seems to be self-supporting. I think one thing to consider is where we want to go in the long term. The FHS [1] specifies binaries that must be in /bin and /sbin, mainly sys-apps/coreutils, sys-apps/util-linux, sys-apps/shadow, and a handful of others (that are related to networking, archiving, system boot and shutdown). Shared libraries needed by these binaries must be in /lib*. Shall we stick to this FHS requirement, as far as it is technically feasible, or shall we do the /usr merge which also has benefits? Or some middle ground between these two solutions? (But I'm with aballier here, that would lead to further inconsistencies and we won't get the advantages of either solution.) Are we even ready to decide on this question yet? What shall we do in the short term? For the upcoming council meeting, the following questions come to mind: - Do we need any new decisions at all? Or are we confident that maintainers (mainly base-system) will do the right thing? - Should binaries stay in /bin or /sbin if the FHS says so, or if they're otherwise needed for booting? (For the time being, until we make up our mind about the /usr merge?) - Are shared libraries needed by binaries in /bin or /sbin to be installed in /lib*? - Do we discourage moving further programs from /usr to /, in order to keep the root filesystem at a small size? Even if this causes inconsistencies in some configurations? Ulrich [1] http://www.linuxbase.org/betaspecs/fhs/fhs/ch03.html --pgp+signed+wfAIEJJNmqYwMbh Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCAAGBQJSB6bUAAoJEMMJBoUcYcJzDT0H/3t9AfFPxYOyTAx0hLUIzoMQ +wPe/Zeypw8Z39Sdy+or2PD9jXOj+nr1Taiq0P0YfCxMlo0nh+H/pj8qjZw4sQ8R ZfUCXVPw/K0oQh8uHvl9p++MRAlzgVC1lXFvtSV4WE8ZoYo6yfa2swiB13bWgBzG hEj6pWCHUWSiXp13sPkwnhBwcwygfg+W93fhWgsb6B5JBs+a0+M0w/SRr88/7EnC u7hU9Xv5sateLUkkfwpfsuGPWZt7uk6MY861ABoZ/RLKk555LGpWYvxBkFHKICWz x5gpnnPGm4obf6+H77xdE+TuVl+2CKK5W2TBsPfKK4xVeXP8CE0SWcTY9Q1V/lw= =Oq17 -----END PGP SIGNATURE----- --pgp+signed+wfAIEJJNmqYwMbh--