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 306C3138010 for ; Fri, 7 Sep 2012 12:30:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D160B21C0CC; Fri, 7 Sep 2012 12:30:07 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 5C66021C0C7 for ; Fri, 7 Sep 2012 12:28:41 +0000 (UTC) Received: from pomiocik.lan (213-238-104-238.adsl.inetia.pl [213.238.104.238]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id B623C33C443; Fri, 7 Sep 2012 12:28:39 +0000 (UTC) Date: Fri, 7 Sep 2012 14:29:41 +0200 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: gentoo-dev@lists.gentoo.org Cc: ciaran.mccreesh@googlemail.com Subject: Re: [gentoo-dev] Unified DEPENDENCIES concept Message-ID: <20120907142941.0c2a7197@pomiocik.lan> In-Reply-To: <20120907124559.68a1b88d@googlemail.com> References: <20120907124559.68a1b88d@googlemail.com> Organization: Gentoo 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-SHA256; boundary="Sig_/hFCaq5RCUZauhhkFl1NIuCy"; protocol="application/pgp-signature" X-Archives-Salt: 7e53e3f1-a619-498a-a8e8-e901d8f0b9d7 X-Archives-Hash: 335968909d882a51aaecb44ce92f5128 --Sig_/hFCaq5RCUZauhhkFl1NIuCy Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 7 Sep 2012 12:45:59 +0100 Ciaran McCreesh wrote: > 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. >=20 > We observe that a typical package will have something like this: >=20 > 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 > )" >=20 > 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 > )" Now please express that using bash variable references instead of the overly verbose expansions. Also, real examples are much more useful than counting and monkeys. This is not mathematics. > 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". >=20 > 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. What is fooness and barness? Because I got lost near the four non-existent word. > 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. Sometimes !=3D always. Sometimes HDEPEND will actually simplify the current state. By moving a few things from DEPEND to HDEPEND, we may be actually able to remove COMMON_DEPEND. Sometimes. > Here's the important bit, which I shall prefix with some stars: >=20 > *** The point of DEPENDENCIES is not to replace n variables with one > *** variable. Yes, it is. > *** The point of DEPENDENCIES is not to provide syntactic sugar over a > *** group of n variables. Yes, it is. > *** 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. Didn't we already prove that the syntactic sugar DEPENDENCIES allows can make the dependency specifications very unclear and not anywhere close to simple? > So here's what DEPENDENCIES solves: >=20 > Firstly, it allows developers to group together foo-related > dependencies and bar-related dependencies by their fooness and > barness, not by their role. >=20 > Secondly, it reduces error-prone duplication. No, it doesn't. It just provides an alternate solution over how we do that now. Does variable substitution ring a bell? > Thirdly, it avoids some fairly obtuse names (BADEPEND? LDEPEND?) in > favour of something a tad more readable. That is a side effect. DEPENDENCIES doesn't disallow us from choosing to use labels like 'd:', 'r:'. Similarly, bash variables don't anyhow stand in the way of using more verbose names. > Here's the other important bit, with more stars: >=20 > *** 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". Really? I think it actually gives concept of 'a package has a few random groups of dependencies, where each group is applicable at one or more of build time, run time, etc and consists of one or more dependencies or groups of dependencies, where each group is applicable at one or more of build time, run time, etc (which may or may not be the same as parent group) and consists of one or more dependencies or groups of dependencies, where each group is applicable at one or more of build time, run time, etc (which may or may not be the same as parent group) and consists of one or more dependencies or groups of dependencies, where each group is applicable at one or more of build time, run time, etc (which may or may not be the same as parent group) and consists of one or more dependencies or groups of dependencies, where each group is applicable at one or more of build time, run time, etc (which may or may not be the same as parent group) and consists of one or more dependencies or groups of dependencies, where each group is applicable at one or more of build time, run time, etc (which may or may not be the same as parent group) and consists ...' > 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: >=20 > DEPENDENCIES=3D" > build: > cat/first > build+run: > cat/second > cat/third > cat/fourth > run: > cat/fifth >=20 > foo? ( > build: > foo/one > build+run: > >=3Dfoo/two-2.34[monkeys] > run: > foo/three > ) >=20 > bar? ( > build+run: > bar/one > run: > bar/two > bar/three > bar/four > ) >=20 > build: > baz? ( > baz/one > baz/two > ) >=20 > fnord? ( > fnord/one > )" >=20 > Here are the rules for working out which labels apply to a given spec: >=20 > 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. These are the rules for a machine. People don't actually read dependencies sequentially. Provide a good algorithm which works from any position. > 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. Yes, that's something you could work on instead of throwing a lot of work on us just to reinvent the wheel your way because you believe that your bicycle is much better when it has square wheels. > These rules are mostly for flexibility: if developers sometimes prefer > to group things by role rather than by fooness, then that's possible > too. >=20 > 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. The algorithm you presented above was technicality as well. So, now that your forked the thread shall we repeat all the disadvantages which you love to forgot to mention? --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/hFCaq5RCUZauhhkFl1NIuCy Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iJwEAQEIAAYFAlBJ6LcACgkQfXuS5UK5QB1OGgQAsKsIQgLngmpxjtELco4egwvE LEds1NqkDh0o762KI406s+q3g+gmmeYcQFWOVNRRgqx4Q9BYFfZQFULG+scaf/jk nasVHpCo88vLAEle+sR5+ewvwpwxdVvXovNTLJ42fR1HvwNkpnl9PleK66YZT31c L89ZvAOV6CrZdlLv7FA= =vOxx -----END PGP SIGNATURE----- --Sig_/hFCaq5RCUZauhhkFl1NIuCy--