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 BDB64138010 for ; Tue, 18 Sep 2012 13:29:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2595721C0F5; Tue, 18 Sep 2012 13:28:43 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 83D0C21C0FB for ; Tue, 18 Sep 2012 13:27:09 +0000 (UTC) Received: from [192.168.1.145] (CPE002401f30b73-CM001cea3ddad8.cpe.net.cable.rogers.com [99.240.69.152]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id AEAB033D74A for ; Tue, 18 Sep 2012 13:27:08 +0000 (UTC) Message-ID: <505876A6.2050009@gentoo.org> Date: Tue, 18 Sep 2012 09:27:02 -0400 From: Ian Stakenvicius User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120731 Thunderbird/10.0.6 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal References: <20120916135211.GC23030@localhost> <20120916153949.05ab795a@googlemail.com> <20120916160528.GD23030@localhost> In-Reply-To: <20120916160528.GD23030@localhost> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: ed3cacb1-aaf0-46d0-84d3-e29b007d9920 X-Archives-Hash: 977adf203d1b2d8001fd05617fa7c31f -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 16/09/12 12:05 PM, Brian Harring wrote: > On Sun, Sep 16, 2012 at 03:39:49PM +0100, Ciaran McCreesh wrote: >> There's also the issue of what negations do at the top level... > > Yeah, I did skimp on that one; technically speaking, negations > aren't required if they prove too much of a pain in the ass. > Negation at the top level could be interpretted two ways: > > 1) negating against all possible dep types; thus a !dep:build? > would be dep:post,run? . Too slick in my view, but who knows, > othes may think it straight forward. > > 2) Treat it as a negation of the implicit dep:build,run; meaning > !dep:build? would be dep:run?. > > Unsure of which is preferably at this juncture. > Proposal: Negation only works within the current context. Simpler to understand that way. So if the implicit dep:build,run is going to be kept (iirc the glep says this is optional and for convenience, so if we dropped it in favour of always forcing it that might be good), #2 would apply. This would also infer that: dep:build? ( !dep:{anything but build}? ( something ) ) would have no meaning and the "!dep:{anything but build}?" condition would just be ignored. Probably, without a QA warning since I could see eclasses perhaps providing something in a variable or function output that might be processed in this manner. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iF0EAREIAAYFAlBYdqYACgkQ2ugaI38ACPB41gD4ygy9SxFODJb/TlUp+23cZ36s D+/c6gCaGXIPVoDGlQD/fsE6TcBsDnovBTVA0db4s811rTuih7JpX5LRDuABjfk= =0eGL -----END PGP SIGNATURE-----