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 51D57138010 for ; Fri, 7 Sep 2012 11:52:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 07EB421C0B5; Fri, 7 Sep 2012 11:51:03 +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 CED35E0540 for ; Fri, 7 Sep 2012 11:48:00 +0000 (UTC) Received: by wibhm2 with SMTP id hm2so1966509wib.10 for ; Fri, 07 Sep 2012 04:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:x-mailer:mime-version:content-type; bh=8h9bMhsCmk8qRLHichQ5ow2CWNOBXdvtDttYbg0p/eg=; b=ynrvdeydmltz0bM3YO+5X+wmYj06cfZPzJm709ek6Q8lCiVOrAKWz8ZnxG1JXsg681 Tg0vdQ91nCtU7ztRZs/8QLsQIh2SQV5Y8nAxDSIuoZuezzSzB6DvLyvfp2MgD7gf317g GsKZv+/OghRrvP3KRYw0YOLa20lFVsn7181JNpMjCsfZblAssIj+OyvKNpuGpE+sl9vZ hUMwrUrxaJLfA28Zd5nzVgSJ6VjlZjeyQbTE/Jb1JoKvTGAGQo4OGLeQgREj92khq7++ FG16LYbSDwhuQEWV3Y/tXRH73PiK9pBK97yRGFPHvnYsrFWYHo/sS68Z9MIFkt8ZiTmn b0YA== Received: by 10.216.197.162 with SMTP id t34mr3277013wen.5.1347018479894; Fri, 07 Sep 2012 04:47:59 -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 hv8sm9342060wib.0.2012.09.07.04.47.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Sep 2012 04:47:59 -0700 (PDT) Date: Fri, 7 Sep 2012 12:45:59 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Unified DEPENDENCIES concept Message-ID: <20120907124559.68a1b88d@googlemail.com> 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_/XwEEBZXnV7r_Gt6/MwkeCVU"; protocol="application/pgp-signature" X-Archives-Salt: 3e99c2f9-363e-415a-ae63-524427563902 X-Archives-Hash: eed909b7f1bfcdc5a000cbe0cbac8ccc --Sig_/XwEEBZXnV7r_Gt6/MwkeCVU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Since DEPENDENCIES hasn't been written up in a Gentoo-friendly manner, and since the Exherbo documentation doesn't seem to suffice to explain the idea here, here's some more details on the DEPENDENCIES proposal. We observe that a typical package will have something like this: DEPEND=3D" cat/first cat/second cat/third cat/fourth foo? ( foo/one >=3Dfoo/two-2.34[monkeys] ) bar? ( bar/one ) baz? ( baz/one baz/two ) fnord? ( fnord/one )" RDEPEND=3D" cat/second cat/third cat/fourth cat/fifth foo? ( >=3Dfoo/two-2.34[monkeys] foo/three ) bar? ( bar/one bar/two bar/three bar/four )" Note how many dependencies that we think of as being "the same" are listed in two places, and are not in any way "the same". Note also how the foo-related things, the bar-related things etc cannot be grouped together by their fooness or barness, but are rather grouped by their DEPENDness and RDEPENDness. Right now we've just got three variables. In a not too distant EAPI, it will be considerably more than three. We also have duplication; with HDEPEND, this will sometimes become triplication. Here's the important bit, which I shall prefix with some stars: *** The point of DEPENDENCIES is not to replace n variables with one *** variable. *** The point of DEPENDENCIES is not to provide syntactic sugar over a *** group of n variables. *** The point of DEPENDENCIES is to allow a package's dependencies, *** which can be very complicated, to be expressed accurately and *** simply, in a way friendly to how developers deal with dependencies *** in practice. So here's what DEPENDENCIES solves: Firstly, it allows developers to group together foo-related dependencies and bar-related dependencies by their fooness and barness, not by their role. Secondly, it reduces error-prone duplication. Thirdly, it avoids some fairly obtuse names (BADEPEND? LDEPEND?) in favour of something a tad more readable. Here's the other important bit, with more stars: *** It does it by replacing the concept of "a package has build *** dependencies, run dependencies, etc" with "a package has *** dependencies, and each dependency is applicable at one or more of *** build time, run tme, etc". We could just mark each dependency individually by when it's applicable. But that turns out to be quite verbose, since packages have fairly long lists of dependencies of the same kind. So here's a much more concise syntax: DEPENDENCIES=3D" build: cat/first build+run: cat/second cat/third cat/fourth run: cat/fifth foo? ( build: foo/one build+run: >=3Dfoo/two-2.34[monkeys] run: foo/three ) bar? ( build+run: bar/one run: bar/two bar/three bar/four ) build: baz? ( baz/one baz/two ) fnord? ( fnord/one )" Here are the rules for working out which labels apply to a given spec: We have a "labels stack" when parsing. Initially, the value "build+run" is on the top. Whenever we encounter a block ("( )", "use? ( )" etc), we duplicate the top value of the stack, and when we leave the block we pop the value off. Whenever we encounter labels, we replace the top value on the stack with those labels. Whenever we encounter a spec, its associated labels are those on the top of the stack. To avoid weirdness, so long as we're inside a || block, use of labels is forbidden. Note that this is a reflection of the current ambiguity as to what DEPEND=3D"|| ( a b )" RDEPEND=3D"|| ( a b )" means (can you build against a, and run against b?), and if we're wanting to tidy that up, that should be an independent proposal. These rules are mostly for flexibility: if developers sometimes prefer to group things by role rather than by fooness, then that's possible too. The rules for eclass merging need changing too, to add a ( ) around values rather than merely appending. This is a technicality, and isn't developer visible. --=20 Ciaran McCreesh --Sig_/XwEEBZXnV7r_Gt6/MwkeCVU Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBJ3nsACgkQ96zL6DUtXhF4SwCgtWj7Cqprq804u9Iu+ksMBzqA BdwAoN917SJydSRD2Rz4DArLkj3tNOPa =2Qk1 -----END PGP SIGNATURE----- --Sig_/XwEEBZXnV7r_Gt6/MwkeCVU--