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 578F7138010 for ; Sun, 16 Sep 2012 17:04:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4191621C048; Sun, 16 Sep 2012 17:03:46 +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 73D5D21C06D; Sun, 16 Sep 2012 17:01:35 +0000 (UTC) Received: by weyt57 with SMTP id t57so3661937wey.40 for ; Sun, 16 Sep 2012 10:01:34 -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=OmC0O0Nm1T4GCF0pL4ouia2hQimiCPC0IJcjPUQZKKo=; b=v9sGeWBW6UJcixcTg4PhtbDnZK9B+VDZDkYKYFFLdNNALhvTDb9Zx541SmaQd8+ej6 OoIDCsFwt+N9iL6B77f2bkS2e9f4PzxqaDjzMyymoGiyWRUvDu9ALf00DINlagn/T4gt 0+hvcIi/fMsRTDrh2Tp9ccq/zCg+zTFUjeMOhke2++FoI3XLhZuuvif5bIDOueNzEUmv LX6A0/AIV1gbgg8Tl7nLPJb1ONJHRwx5VvVzKi/QbDl3f3sAZ3UhvVqERaXaC0fJe2q7 h/9OJo4ZevEbwUKuuz154xYsO0ibNRwTUuo45q6sU8YF1pfyaS5siLZTBiQmsne7o2CT 391Q== Received: by 10.216.202.8 with SMTP id c8mr26147weo.82.1347814894588; Sun, 16 Sep 2012 10:01:34 -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 ct3sm12904615wib.5.2012.09.16.10.01.33 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Sep 2012 10:01:34 -0700 (PDT) Date: Sun, 16 Sep 2012 17:59:21 +0100 From: Ciaran McCreesh To: Brian Harring 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: <20120916175921.4f01661a@googlemail.com> In-Reply-To: <20120916160528.GD23030@localhost> References: <20120916135211.GC23030@localhost> <20120916153949.05ab795a@googlemail.com> <20120916160528.GD23030@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 Linux mail 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_/alhB6i.4b5j4jWug1Osw3Vk"; protocol="application/pgp-signature" X-Archives-Salt: 1006c2a9-fe03-47ba-a206-fd8e8496dcf0 X-Archives-Hash: b4f789ff485ec2f3623cf459e4a4e620 --Sig_/alhB6i.4b5j4jWug1Osw3Vk Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 16 Sep 2012 09:05:28 -0700 Brian Harring wrote: > > Labels doesn't have this problem: it doesn't try to reuse an > > existing syntax precisely because the existing syntax is extremely > > awkward for this kind of thing. >=20 > Labels have a human comprehension problem, and require a fair amount=20 > more work for the various parsers. >=20 > You may not agree on that view, but there seems to be some consensus=20 > on that (as much as one ever gets in gentoo at least). I've never heard that view coming from anyone who has actually used labels. It's only come from people who haven't tried using it, and who have a history of disagreeing with anything that says 'Exherbo' on it. You're taking about consensus among people who have never tried it because they don't like it; consensus among people who have tried it is that the labels syntax is good. > My intention is a syntax/format that is natural to the dev, and=20 > doesn't force them to do silly shit. Labels already solve that. We know because we've got extensive experience with them. Adoption of labels has been demonstrated to be easy, both for former Gentoo developers and for people who haven't previously written ebuilds. We *know* that labels are easy to learn and easy to use. We also know that they admit an efficient implementation, that they compose nicely, that they allow dependencies to be specified accurately and that they scale to larger numbers of dependency classes. > > Your syntax also prevents the following: > >=20 > > DEPENDENCIES=3D"foo? ( $(make_foo_deps blah) )" >=20 > Err, no it doesn't. I think you're reading too literally into the=20 > example mplayer translation I put in the doc- again, that was just a=20 > quicky, automated form, you can push dep:blah down beneath=20 > conditionals as necessary/desired. >=20 > If you see something claiming otherwise, or implying otherwise in the=20 > glep, please tell me exactly where so I can fix the wording. The point is that nesting prevents composition. Labels are context insensitive, which allows groups of dependencies to be added anywhere, whereas dep: blocks can only be added if the surrounding groups are specified in a particular way. > 1) first, collapse dependencies down, than render the *DEPEND views, > thus enabling easy and quick initial integration; effectively > no impact on the api/functionality of the PM at this phase. Specification in terms of rendering has a huge problem, though. Remembering the crazy rules Gentoo has for || ( flag? ( ) ), what does this do? || ( dep:build? ( a ) dep:run? ( b ) ) > > Ultimately, it comes down to the observation that the flag? ( ) > > syntax is strongly nested and hierarchical, but dependency roles > > aren't. >=20 > There is a bit of truth in that views on flag? ( ) vs the random-ass=20 > context labeling (which is hierarchical- keep in mind your stack=20 > pushing/popping confusion). There's not any stack confusion in practice. Labels only have slightly complicated rules to allow every side case to be covered. You're taking the "don't do that" approach to nesting weirdness; labels go the "specify it precisely" route instead. > > Labels can give all the advantages of your proposal (including the > > backwards compatibility, if that's desired), but without the need to > > shoehorn the idea into an unsuitable syntax. >=20 > If you want your proposal to go anywhere, you're going to need a=20 > better transition plan then "and.... then devs convert their=20 > ebuilds/eclasses". I'd suggested it prior, but no traction there. Your "rewrite *DEPEND" approach can just as easily be used with labels. --=20 Ciaran McCreesh --Sig_/alhB6i.4b5j4jWug1Osw3Vk Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBWBW0ACgkQ96zL6DUtXhH2rQCfT9cqtyA8LzC6iHnfO7B535bo 88MAoOaCIdFDBhlyTbC8gNYoUSb8nLI6 =UQXk -----END PGP SIGNATURE----- --Sig_/alhB6i.4b5j4jWug1Osw3Vk--