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 A2BB813877A for ; Mon, 4 Aug 2014 07:26:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3CFA6E0871; Mon, 4 Aug 2014 07:26:19 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 498A3E07E6 for ; Mon, 4 Aug 2014 07:26:18 +0000 (UTC) Received: from pomiot.lan (77-253-194-255.adsl.inetia.pl [77.253.194.255]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id C783D340033; Mon, 4 Aug 2014 07:26:15 +0000 (UTC) Date: Mon, 4 Aug 2014 09:26:42 +0200 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= To: Ulrich Mueller Cc: gentoo-dev@lists.gentoo.org, pms-bugs@gentoo.org, dev-portage@gentoo.org Subject: Re: [gentoo-dev] Re: The meaning of || ( a:= b:= ) dependencies Message-ID: <20140804092642.77ebc2df@pomiot.lan> In-Reply-To: <21471.8946.528694.84451@a1i15.kph.uni-mainz.de> References: <20140804004450.5aa146ec@pomiot.lan> <21471.8946.528694.84451@a1i15.kph.uni-mainz.de> Organization: Gentoo X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; 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-sha512; boundary="Sig_/Tf6D9rXdsigcJB+nQa_Tnic"; protocol="application/pgp-signature" X-Archives-Salt: a107964c-0724-4ac8-964f-4cd89bb21789 X-Archives-Hash: 996d23f6a974c714a95e5e4148d343d5 --Sig_/Tf6D9rXdsigcJB+nQa_Tnic Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Dnia 2014-08-04, o godz. 08:06:42 Ulrich Mueller napisa=B3(a): > >>>>> On Mon, 4 Aug 2014, Micha=B3 G=F3rny wrote: > > In particular, I was thinking we could reuse this syntax: >=20 > > || ( A:=3D B:=3D ) >=20 > > to express any-of dependencies that do not support runtime switching > > of providers -- since that is pretty much what :=3D does to slots. > > This would save us from creating a new syntax like '||=3D ()' [1]. >=20 > Please don't, because it makes things pretty much unreadable. If you > want an operator like || ( ) but without runtime switching, then > define one (e.g., <<=3D or ||=3D as suggested in [1]), but don't try > to inherit properties from its children. Reasonable. However, as I see it, we'll end up having up to four different operators: - || that is deprecated yet everyone will still use it (like they don't use :* right now), - ||* that will be used scarcely, - <<=3D that would be the preferred variant for compile-time switches yet many people will not use it because it has different characters than '||' [we could try maybe '||<' so that people will still see it as replacement for '||'], - ||=3D that most people would use forgetting about '<<=3D' [or '||<']. So, banning '|| ( A:=3D B:=3D )' in a future EAPI sounds reasonable. However, there's still the matter of setting current Portage behavior because I don't we should keep the non-predictable magic. What should be the current behavior then? Should we assume that all '||' are not well-defined and need to be compile-switchable? Or try to invent heuristic like I suggested? --=20 Best regards, Micha=B3 G=F3rny --Sig_/Tf6D9rXdsigcJB+nQa_Tnic Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJT3zWzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZO7VAQAIwiUVuspTULWRqX836/t2+l 2M8oURDjjKV7Noe1RCgZUHbDEOr8m7RSOnj2XrvYe4TvK7964W3ZqxWDCg6lw7Rg m00BqNwyLZXSqDvc4PIAagCIC/hQsV2v4YDvxM6FL95+E4a/8QB6Yrw4uRIE4CVV /uZBOb3kI6jypl+z/ZdpFIq4awGUKNA4KVZBqYbUVZaIWSBrkAHnyNr4twrNV033 /a8Xl3V8BP5B/EgF7bzQHsccDpRd/N/syRtkUmjJ2VrINutEhS5K9EfTAfhK5bmz FskKmRqKO5J/ioTygGRTg4JzLovHbEIouKjoQ0g4E1nLvW2cp/XEySpFPeh1toPb ct8rf+SFpMWr0M3m3QWFiW0n89KFsGZkXq+SnaF6Tk6SwaNOMNwJd83ZdesANX7M tE7KdHPlqNSSYIN4zq7MggCK+q3zviA2vwN0x5okUbHQkWVhFixP+s+arst8VtbC GZWvoWo2tktJbVupTWdyLcbX3qAnYHn76m1S1xmZ2iBWrHizXIfmEEnGm8z8dVY/ IcUWrhqh41YMRDrz5wBynIvymXGAtem+4q+TKYT+JumVyxCk2BRT34kfenD1dEJ6 M6RpZH16OM7v4NbSylpRBsxxZg77Js3hAIxTHGYtfjXOT1LJefvaPj7qfyd2M8a7 zWbZ9YFZgNzXvwG4bSCf =agHP -----END PGP SIGNATURE----- --Sig_/Tf6D9rXdsigcJB+nQa_Tnic--