From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 9B898138010 for ; Mon, 1 Oct 2012 09:18:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EBC88E04D2; Mon, 1 Oct 2012 09:18:21 +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 ; 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 To: Brian Harring Cc: gentoo-pms@lists.gentoo.org, gentoo-dev@lists.gentoo.org Subject: 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: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Package Manager Specification discussions X-BeenThere: gentoo-pms@gentoo.org X-BeenThere: gentoo-pms@lists.gentoo.org Reply-To: gentoo-pms@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: 8d940344-251d-43e9-bbdb-65eba7beb9e8 X-Archives-Hash: 2d1fb67e52778d3130b5a85f62155782 --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 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--