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 0FFD3138010 for ; Sun, 16 Sep 2012 14:42:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9492FE04EB; Sun, 16 Sep 2012 14:42:07 +0000 (UTC) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by pigeon.gentoo.org (Postfix) with ESMTP id E493EE0486; Sun, 16 Sep 2012 14:42:06 +0000 (UTC) Received: by wibhm2 with SMTP id hm2so1064583wib.10 for ; Sun, 16 Sep 2012 07:42:06 -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=JG0KraUN8iIHWJrKymOf9NXk0WduTTbZLrHYyuxD3DI=; b=dTCkIDvAyAf/w0UAv3TNC2VCfYT/OusrraBBeBSLF+uo012iX8xWQp8ZFpYcWSYog9 7R+yhDyKg1EQlSlIVSJBfoVZlwceTX+2rXthZ5Ko2I1lvIemAkhHoXj1g0NfoKi2PozZ PRDSPZvI+CA7SQE8Iw/C6YM39yvfyxDR5f+/y9fL4qGAOe5xBjoECWo9av/iaLHqxOWB IROnmBHSp9JsQqKRIbNS5E1U9JEjD8dmf/KacxwLLhp50nG5knPoUVQQ9XoI80Mzsm1i WygyCy8pDiD2bbmG1Nsa7a9O4NnIKzPf7I0xhyGthxdr+7eyVoltof+GQ0Qct/txU6US B8+A== Received: by 10.216.134.101 with SMTP id r79mr4552018wei.60.1347806526073; Sun, 16 Sep 2012 07:42:06 -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 b7sm17653142wiz.9.2012.09.16.07.42.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Sep 2012 07:42:05 -0700 (PDT) Date: Sun, 16 Sep 2012 15:39:49 +0100 From: Ciaran McCreesh To: gentoo-pms@lists.gentoo.org Cc: ferringb@gmail.com, gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal Message-ID: <20120916153949.05ab795a@googlemail.com> In-Reply-To: <20120916135211.GC23030@localhost> References: <20120916135211.GC23030@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_/D6vMRAWxxXcp6vi4urTdErW"; protocol="application/pgp-signature" X-Archives-Salt: 833cbfe9-0c8e-4955-92e5-88d55f3d29d5 X-Archives-Hash: f7c164ffadb46b6cced12b6f66c16346 --Sig_/D6vMRAWxxXcp6vi4urTdErW Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 16 Sep 2012 06:52:11 -0700 Brian Harring wrote: > The live version of the doc is available at=20 > http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependenc= ies.html=20 I think you're being a bit glib with your dismissal of the labels parsing scheme. You've got the following problems, that labels don't have: You dismiss the dep:build? ( dep:run? ( ) ) problem as "don't do that". 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. You say there's an implict "build,run". This can't be an implicit "dep:build,run? ( )" using that syntax, however, since then you wouldn't be able to put a dep:post? inside it by the above. So again you've got a special case to deal with simply because of the syntax -- your syntax doesn't correspond directly to the meaning of dependencies. There's also the issue of what negations do at the top level... You discourage grouping of dependencies by the use flag that selects them (see xscreensaver in your examples). Logically, "xscreensaver related things" belong together. Your negation example also tries to bring related dependencies together. But it's a mess. What if one of the dependencies was a build dependency, and one a run dependency? You'd end up with something silly like this: dep:build,run? ( !dep:run? ( dev-util/diffball ) !dep:build? ( dev-util/bsdiff ) ) Your syntax also prevents the following: DEPENDENCIES=3D"foo? ( $(make_foo_deps blah) )" and would encourage something like this instead: DEPENDENCIES=3D" dep:build? ( foo? ( $(make_foo_build_deps blah) ) ) dep:run? ( foo? ( $(make_foo_run_deps blah) ) ) dep:build,run? ( foo? ( $(make_foo_build_and_run_deps blah) ) ) which makes it much harder for the foo.eclass authors to switch what kinds of dependencies they use. For example, if foo.eclass starts needing an install dependency, your syntax requires every foo user to be updated, whereas labels does not. To get around that, you'd have to allow deeply embedded dep: blocks. You're also still speaking in terms of "rendering DEPEND" etc. That's not really what we want, though. As you've observed, a lot of atoms are in both DEPEND and RDEPEND. Conceptually, it makes much more sense to consider such an atom to be a single dependency that is both a build and a runtime dependency than it does to consider it as two unrelated dependencies. This is especially the case now that we have :=3D slot dependencies. Ultimately, it comes down to the observation that the flag? ( ) syntax is strongly nested and hierarchical, but dependency roles aren't. 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 Ciaran McCreesh --Sig_/D6vMRAWxxXcp6vi4urTdErW Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBV5LwACgkQ96zL6DUtXhHH+QCcCBKOIaN2gIFBmcieg3B4dQW9 9TQAmwXoMLBGvQm9M0DaByhlXTh5fKfU =10al -----END PGP SIGNATURE----- --Sig_/D6vMRAWxxXcp6vi4urTdErW--