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 <gentoo-dev+bounces-51394-garchives=archives.gentoo.org@lists.gentoo.org>)
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 <gentoo-dev@lists.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>;
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 <gentoo-dev@gentoo.org>; Fri, 4 May 2012 15:06:30 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <lnx-gentoo-dev@m.gmane.org>)
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 <gentoo-dev@gentoo.org>; 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 <gentoo-dev@gentoo.org>; 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 <slong@rathaus.eclipse.co.uk>
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: <jo0r94$oci$1@dough.gmane.org>
References: <20353.41193.129711.306663@a1i15.kph.uni-mainz.de> <20120408220422.GA26440@kroah.com> <CAGfcS_mLRBCEuvs2gQu8Ov9XD2MoKmFjCn+giLFsLLnvikoYOw@mail.gmail.com> <jlv8e2$fdj$1@dough.gmane.org> <4F833687.4040004@gentoo.org> <jm2q2o$4n7$1@dough.gmane.org> <4F8503DF.1010802@gentoo.org> <jm43b9$a0e$1@dough.gmane.org> <4F85E21C.4060106@gentoo.org> <jmvr06$96o$1@dough.gmane.org> <CAGfcS_nPz=6kGg49kwZ-6GGAeB0fixzUQxyyXbU8-bbO0ndKng@mail.gmail.com> <jn04lk$q2i$1@dough.gmane.org> <CAJ0EP40AR_AEb_N4naXoewGFsZUkpCbfcWm_+Vf1W46cGtpCEw@mail.gmail.com> <20371.51767.784259.131892@a1i15.kph.uni-mainz.de> <jn0iou$8m6$1@dough.gmane.org> <4F94462C.9000006@gentoo.org>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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 ;-)