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 1SQSSc-0003SJ-Re for garchives@archives.gentoo.org; Sat, 05 May 2012 00:02:55 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CC5CAE0484 for ; Sat, 5 May 2012 00:02:53 +0000 (UTC) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by pigeon.gentoo.org (Postfix) with ESMTP id CE32AE068C for ; Fri, 4 May 2012 23:06:40 +0000 (UTC) Received: by obbuo19 with SMTP id uo19so5589245obb.40 for ; Fri, 04 May 2012 16:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=hYW7MbbOQW0NU9ga9SPMPrDNSroq51UcbIvS9ZDJR6o=; b=Jx5iQrPyxXCEXmNsMGBS+Z8YeUjvk3DY7W5puPGMR0e2cFFTDtSZ2B0L6riZSywAlR UV4gGL2qGTv10FZ7niJde4EcRuBX6cC5CT24LgCTg2qSUsOIagGwVKtsI9XaCmNZQ3C1 6FudyfPpLOpzlA18VOSBzu1DSKOgnvK8eXHmwdnKhYC6G0nMNPX03V55WV6VEYL/rC8k xysR5zVYXu91BTWkInmGr3Y7FINnXTiAwXD42frk4CInUS8EMFSgySJhPfuvAeGD2dyK rlz/mWrYRPxrFG1p0JSsTm2OCBtOgthZ7As0Bx5dH4Oqyg2pnSRyReprKrdIvw8Bz7xF vDXA== Received: by 10.182.31.102 with SMTP id z6mr11016145obh.78.1336172799908; Fri, 04 May 2012 16:06:39 -0700 (PDT) Received: from linux1 (cpe-76-187-77-158.tx.res.rr.com. [76.187.77.158]) by mx.google.com with ESMTPS id aj16sm8515070oec.4.2012.05.04.16.06.37 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 16:06:38 -0700 (PDT) Sender: William Hubbs Received: by linux1 (sSMTP sendmail emulation); Fri, 04 May 2012 18:06:37 -0500 Date: Fri, 4 May 2012 18:06:37 -0500 From: William Hubbs To: gentoo-project@lists.gentoo.org Cc: council@gentoo.org Subject: Re: [gentoo-project] Council meeting: Tuesday 8th May 2012, 19:00 UTC Message-ID: <20120504230637.GA2183@linux1> Mail-Followup-To: gentoo-project@lists.gentoo.org, council@gentoo.org References: <4FA095CE.3070701@gentoo.org> 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; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <4FA095CE.3070701@gentoo.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: d8fba7e2-642d-4402-bafe-dc0ca122566d X-Archives-Hash: 7cc163911d1a0437f4a81e8ea021501b --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, May 02, 2012 at 02:02:54AM +0000, Jorge Manuel B. S. Vicetto wrote: > 3. Separate /usr partition vote of last meeting (20 minutes) Hello Council Members, I was told that responding here is the best way to add information to the discussion you will have in the upcoming meeting about this vote, so that is why I am replying to this thread. Everyone seems to be focused on udev, but this issue goes a bit further than udev. I'm sure you have all read the document asserting why separate /usr without an initramfs is broken, but I'm going to reference it here just in case [1]. The following are concerns I have about us mandating that separate /usr without an initramfs is how we are going to do things: - We would have to introduce a new top-level directory, /share, as a counterpart to /usr/share. This would be for programs that currently read data from /usr/share but need to be made available in early boot. - Anything we might use at all during early boot must be stored in /, along with all of its dependencies. - Any program that hooks itself into udev must automatically be moved to / along with its dependencies. - The locale logic in linux always looks for information in /usr/share/locale. We would need to patch gettext to look in /share/locale as well. - If we decide a program needs to go into /, it, and all of its dependencies will need to be customized in the build process, and probably patched, to not refer to anything outside of /. - / will not be able to be kept small, which is a concern of some of our users. - Any patches we come up with to handle these issues most likely wouldn't be accepted into upstream, so we would be carrying them forever. If you use an initramfs to pre-mount /usr, all of these issues are moot and things just work (tm). Mike's sep-usr use flag option on busybox may do this, but see below. - Separate /usr without initramfs blocks the /usr merge. In my original request to have your vote reviewed, I pointed out the document which asserts that the /usr merge is a good thing and pointed out the thread in which we discussed it on -dev. The arguments supporting it are strong, and I haven't seen any technical argument against it that would not be addressed by using an initramfs with separate /usr. If you are using an initramfs, you will never know when the /usr merge happens, but if you are using something like Mike's option your system is not compatible with the merge. I also want to point out something out of the meeting log: here's the thing who's going to either "port" udev as necessary, or maintain an old version forever? [21:36] we can't proclaim things like this from on high without a route forward I will keep an old version going until the end of time. if udev is moving that way, we can't stay 'old' forever what happens when kernel 3.6 no longer supports it? Then dev(tmp)fs will win. The new udev requires devtmpfs to function. devtmpfs creates the device nodes and udev manages everything else such as permissions, running external programs for certain events, loading kernel modules and creating extra symbolic links to device nodes. I do not see all of that functionality being moved into devtmpfs. So IMO the question still remains. If we take that route, what happens when the newer kernels do not support the older version of udev any longer? There is now a tracker bug open for the tasks which need to be done before newer udevs can be stabilized [2], and the documentation team has an initramfs guide [3]. My position is that we should use initramfs as our default method of supporting separate /usr, because if we don't, we will be hurting our distribution. We will require more and more things to be installed in / which will not be able to be kept small, we will create extra work for our maintainers who will have to maintain custom builds of their packages to support this, and we will block ourselves from doing the /usr merge. Thanks for your time. William [1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken [2] http://bugs.gentoo.org/411627 [3] http://www.gentoo.org/doc/en/initramfs-guide.xml --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk+kYP0ACgkQblQW9DDEZThtcQCfThMz7uDqIiMY7z3YLNGtxMNO vTEAnAgrPz267jz/1yUKmKlbGx1dMKdV =lOrd -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk--