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 1SQK6o-0007AO-QF for garchives@archives.gentoo.org; Fri, 04 May 2012 15:07:51 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7A434E0716; Fri, 4 May 2012 15:07:26 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id CDD8FE06E8 for ; Fri, 4 May 2012 15:06:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 61F341B4050 for ; Fri, 4 May 2012 15:06:37 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.126 X-Spam-Level: X-Spam-Status: No, score=-1.126 tagged_above=-999 required=5.5 tests=[AWL=-0.378, 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 bUVdK-1eYKWy for ; Fri, 4 May 2012 15:06:30 +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 875131B400C for ; Fri, 4 May 2012 15:06:30 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SQK5Q-00048q-46 for gentoo-dev@gentoo.org; Fri, 04 May 2012 17:06:24 +0200 Received: from 91.85.61.115 ([91.85.61.115]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 17:06:24 +0200 Received: from slong by 91.85.61.115 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 May 2012 17:06:24 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steven J Long Subject: [gentoo-dev] Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 Date: Fri, 04 May 2012 16:10:54 +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> <20371.51767.784259.131892@a1i15.kph.uni-mainz.de> <4F94462C.9000006@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: 91.85.61.115 X-Archives-Salt: 3893ceb2-5c70-43d6-bc49-f173cc2706a8 X-Archives-Hash: e8b511c21ae9f4021bd386bdfbab35b8 Mike Gilbert wrote: > On 04/22/2012 05:28 AM, Steven J Long wrote: >> "To clarify, the question is whether or not we support a separate /usr >> _without_ mounting it early via an initramfs." >> >> I hope that settles that particular issue. >> > > Hmm... I see that in Zac's reply, thanks for that. > > Unfortunately, from what I can tell, that clarification was not actually > part of the proposed agenda [5], nor was it directly referenced. So the > subject of the vote still seems open to interpretation. > Chainsaw proposed the item. zmedico immediately clarified that it was about supporting separate /usr without an initramfs mounting it. Chainsaw was asked to describe the issue. He was asked whether a "minimal universal" initramfs was a sufficient solution, and he explicity turned it down. All further discussion was about who would continue to maintain any patches that might be needed. Again, those could not have been needed, unless one were discussing split /usr without an initramfs, since udev with an initramfs already supports a separate /usr. Or do you disagree? To say that it was not referenced in the discussion seems disingenuous: it _was_ the topic of discussion. > Ultimately, the council's only "power" is to stop things from happening > under threat of expulsion from the project. I think it would be a > mistake for this particular council vote to be used as the sole > justification for preventing devs from committing changes that would > require an initramfs for separate /usr support. It simply does not seem > clear enough for that. > Woah, no-one's even talking about anything along those lines. The Council *does* decide on overall technical policy, and this procedure is used for eg resolution of PMS and EAPI issues. Obviously, like all collaborative processes, and indeed policing in general, it only works by consent. There's no issue of changes to udev, since those can be handled at initscript/ busybox-applet level for those who want to continue without an initramfs and split partitioning. There might be future problems with linkage, but I've already stated a couple of times, that the same issues arise for the newer use-case of an initramfs, and it would make sense to tackle those systematically for at least some tools like lvm and mdadm. Given the systematic ability, it's much easier for users to apply elsewhere, and has other uses (basically doing it right is LDEPEND or required-link deps which slot operators do *not* cover.) What's wrong with doing that, so we all cooperate and we all benefit, instead of arguing? Anyhow, wrt what the Council was actually discussing (remember that split /usr with an initramfs is a technical non-issue) as before, I'd like the Council just to clarify. Guess I'll have to raise it on the agenda so they have to discuss it again? Regards, Steve. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)