From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-55204-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id C93F6138010
for <garchives@archives.gentoo.org>; Mon, 1 Oct 2012 09:19:15 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 5BBCBE0676;
Mon, 1 Oct 2012 09:19:06 +0000 (UTC)
Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181])
by pigeon.gentoo.org (Postfix) with ESMTP id 3F960E03E0;
Mon, 1 Oct 2012 09:18:20 +0000 (UTC)
Received: by weyu54 with SMTP id u54so2898728wey.40
for <multiple recipients>; Mon, 01 Oct 2012 02:18:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlemail.com; s=20120113;
h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer
:mime-version:content-type;
bh=/ZlOKOrU7NYpAP1mD/4bMWe//PDCVy21cBdej3lLGF4=;
b=M5dCM+S3u9gG8W9fDxamw32oaKoE+J55+HaSuZpGJlDy9sZ8IPzpTN9a6LQKOWqOYc
GWiCFwnC5PstGGDDOZBNHfCGG+FdznSWmD8esoYHGJxN6vePLNz0+OrxCDm7UIGXQg4n
Ol7FqnfOXfV94RmX6TgMxBSikj33wsklU7ZzuwvmRTWVcsI5Sq/ESG+RqTaPpD61bjmv
vvvzGe8Nq55yA7X1Zmjzh+G8C8nelczrmMVWQDTrWAPJvR7F+sBLG6ZIar1ELbSH/36A
hYPZq7goW81L6ZP9gf9184Wj+vYXy8VobeU2szquqbNgiOiodJCq0I3T8t3bwv3oMzfs
yg0g==
Received: by 10.216.85.149 with SMTP id u21mr7126646wee.147.1349083100148;
Mon, 01 Oct 2012 02:18:20 -0700 (PDT)
Received: from localhost (cpc13-broo7-2-0-cust130.14-2.cable.virginmedia.com. [82.9.16.131])
by mx.google.com with ESMTPS id k2sm17603602wiz.7.2012.10.01.02.18.18
(version=TLSv1/SSLv3 cipher=OTHER);
Mon, 01 Oct 2012 02:18:19 -0700 (PDT)
Date: Mon, 1 Oct 2012 10:15:31 +0100
From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
To: Brian Harring <ferringb@gmail.com>
Cc: gentoo-pms@lists.gentoo.org, gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
Message-ID: <20121001101531.68e11cf3@googlemail.com>
In-Reply-To: <20121001090132.GB14301@localhost>
References: <20120916160528.GD23030@localhost>
<20120916175921.4f01661a@googlemail.com>
<20120925224614.GF26094@localhost>
<20120929170509.63efef70@googlemail.com>
<20120930201453.GC2180@localhost>
<20120930213018.22fe16f3@googlemail.com>
<20120930214214.GE2180@localhost>
<20120930225340.126b1027@googlemail.com>
<20120930235656.GA10800@localhost>
<20121001081349.59ba2745@googlemail.com>
<20121001090132.GB14301@localhost>
X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.11; x86_64-pc-linux-gnu)
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: multipart/signed; micalg=PGP-SHA1;
boundary="Sig_/dX7KIHAPHGnO_Q0NVlSd=du"; protocol="application/pgp-signature"
X-Archives-Salt: b4d536d5-f14e-4416-97fa-9466ccd6686d
X-Archives-Hash: c5b88ed638327bc119052f9cb7ca2be6
--Sig_/dX7KIHAPHGnO_Q0NVlSd=du
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
On Mon, 1 Oct 2012 02:01:32 -0700
Brian Harring <ferringb@gmail.com> wrote:
> On Mon, Oct 01, 2012 at 08:13:49AM +0100, Ciaran McCreesh wrote:
> > x? ( build: a run: b ) *is* nested "conflicting".
> >=20
> > You're still failing to understand the point of labels parsing
> > rules, though: the point is to make uses like the above well
> > defined and consistent.
>=20
> I understand them just fine; you're just either very fucking daft,=20
> which I have a hard time believing, or lieing through your teeth=20
> (which fits a decade of behaviour including multiple suspensions for=20
> exactly that behaviour).
>=20
> Implicit labels context is build+run. Meaning the following
> > x? ( build: a run: b ) *is* nested "conflicting".
>=20
> is actually
>=20
> build+run x? ( build: a run: b )
>=20
> Which isn't a nested conflict- subset, not conflict.
As I said right at the start, you're special-casing the top level to
something that can't normally be expressed using the syntax.
> You argue labels are required so people can do nested conflicts;=20
> meaning the following extreme example:
>=20
> run x? ( build: a test: b )
>=20
> And as I nicely pointed out, /not a single fucking exheres/ does
> that. you've yet to pull out an example contradicting that analysis
> in addition.
No, I argue that having well-defined parsing rules means it doesn't
matter if someone does do that. Meaning, no special case for the top
level.
Your rules require a handler to say "have I seen any dep: blocks
further up the tree than my current position? If yes, handle this dep:
block one way; otherwise, handle it a different way". With labels, all
you do is initialise the label stack with build+run, and then no
special case handling is required.
That's what you should be putting in the GLEP. Not examples, but a big
fat warning that your syntax requires a very strange special case rule
to handle your default build+run behaviour.
> What I truly love about that solution there is that it's both=20
> accurate, and if I play my cards right, I may be able to get a glep=20
> passed calling your proposal academic wankery; minimally, it'll be
> fun from my standpoint to try, so at least something came out of the
> last few emails from you.
Oh come on, we all know that unnecessarily screwing up the syntax won't
make DEPENDENCIES be sufficiently un-exherbo-looking to get it passed...
--=20
Ciaran McCreesh
--Sig_/dX7KIHAPHGnO_Q0NVlSd=du
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlBpXzsACgkQ96zL6DUtXhFYeACgyfOEgNdMXhPWSVlORT2NQGd/
6BwAoNJ1pUDu7p0hP7bpRutwVDebMgfm
=7gVQ
-----END PGP SIGNATURE-----
--Sig_/dX7KIHAPHGnO_Q0NVlSd=du--