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 1SLpIZ-0005vK-MF for garchives@archives.gentoo.org; Sun, 22 Apr 2012 05:25:23 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4B15EE0B16; Sun, 22 Apr 2012 05:25:03 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 000AFE0AE5 for ; Sun, 22 Apr 2012 05:24:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 6B3141B4010 for ; Sun, 22 Apr 2012 05:24:25 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5.5 tests=[AWL=-0.984, BAYES_00=-1.9, RCVD_NUMERIC_HELO=1.164, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJlNOSXqtX6T for ; Sun, 22 Apr 2012 05:24:18 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id B5F411B40EA for ; Sun, 22 Apr 2012 05:24:18 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SLpHR-0005Dc-G1 for gentoo-dev@gentoo.org; Sun, 22 Apr 2012 07:24:13 +0200 Received: from 109.176.242.43 ([109.176.242.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Apr 2012 07:24:13 +0200 Received: from slong by 109.176.242.43 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Apr 2012 07:24:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steven J Long Subject: [gentoo-dev] Re: Re: Re: Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 Date: Sun, 22 Apr 2012 06:28:08 +0100 Organization: Friendly-Coders Message-ID: References: <20353.41193.129711.306663@a1i15.kph.uni-mainz.de> <20120408220422.GA26440@kroah.com> <4F833687.4040004@gentoo.org> <4F8503DF.1010802@gentoo.org> <4F85E21C.4060106@gentoo.org> 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="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 109.176.242.43 X-Archives-Salt: 827c1efa-e17e-4d87-ac41-0261aa5ab4b1 X-Archives-Hash: bfcc5eb0a7fdbac78a3e95cb870b712e Rich Freeman wrote: >> The Council has voted that Gentoo continue to support that subset, >> without an initramfs. > (The "subset of users" being those who do not need udev before localmount.) > Citation, please? > New udev and separate /usr partition In my opinion, a separate /usr partition has been a supported configuration for a very long time and should remain so. Chainsaw: So to clarify a universal initramfs is not enough? Betelgeuse: No. That is additional work for a clearly broken package. So we must support separate /usr *without* an initramfs. who's going to either "port" udev as necessary, or maintain an old version forever? I will keep an old version going until the end of time. dberkholz: My plan is to patch reasonable behaviour back into udev, and going with the upstream releases as long as it is feasible. To confirm again, that this is about without initramfs: sure i can. maintain old udev-XXX forever, put an elog in new udev that says "if you want separate /usr without initramfs, install old udev, mask new, or whatever" And again, I ask: if it were *not* about running udev without an initramfs, then why would anyone even be discussing the possibility of patching or forking? The only question is whether running without an initramfs means the same thing as not requiring udev before localmount. I contend that it is, since the basic requirement we've been given is that udev as a service requires /usr and /var mounted before starting, since some devices already require scripts which are in /usr or access /var (and going forward effectively can require a script anywhere.) Wrt udev linking to /usr/lib, it seems that any such linkage would need to be satisfied in an initramfs too, so the same data could be used for people who don't have an initramfs (how we deal with it on our systems is up to us.) I would dearly love to hear a walkthrough of how you deal with device nodes created by udev which are required for udev to start in your initramfs, but it does not affect the basic requirement for our use-case: that udev is not needed for localmount. Regards, Steve. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)