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 C79E51386F3 for ; Wed, 12 Aug 2015 17:22:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7DCF0142B9; Wed, 12 Aug 2015 17:22:17 +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 5D996142A4 for ; Wed, 12 Aug 2015 17:22:16 +0000 (UTC) Received: from localhost (AMontpellier-655-1-335-201.w90-0.abo.wanadoo.fr [90.0.79.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id B5F2F34082B for ; Wed, 12 Aug 2015 17:22:14 +0000 (UTC) Date: Wed, 12 Aug 2015 19:22:09 +0200 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: useflag policies Message-ID: <20150812192209.754f9f09@gentoo.org> In-Reply-To: <55CB7D23.405@gentoo.org> References: <55C7AC24.2040503@gentoo.org> <55C9CA32.3060300@gentoo.org> <55C9F189.10102@gentoo.org> <20150812052120.5a83c3b1@googlemail.com> <20150812150349.00f8c8f9@gentoo.org> <21963.24971.636400.468846@a1i15.kph.uni-mainz.de> <55CB669F.8020501@gentoo.org> <21963.30553.849375.599948@a1i15.kph.uni-mainz.de> <55CB7AF5.4070705@gentoo.org> <20150812190037.316442b2@gentoo.org> <55CB7CC6.40406@gentoo.org> <55CB7D23.405@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 37d3d8fb-dd43-4d32-bf95-06b462efd3e1 X-Archives-Hash: e83e41db733fb5b61a07d976bfe61aac On Wed, 12 Aug 2015 13:06:43 -0400 Ian Stakenvicius wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 >=20 > On 12/08/15 01:05 PM, Ian Stakenvicius wrote: > > On 12/08/15 01:00 PM, Alexis Ballier wrote: > >> On Wed, 12 Aug 2015 12:57:25 -0400 Ian Stakenvicius=20 > >> wrote: > >=20 > >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > >>>=20 > >>> On 12/08/15 12:42 PM, Ulrich Mueller wrote: > >>>> On Wed, 12 Aug 2015, Ian Stakenvicius wrote: > >>>>> 2 - is there a particular reasoning for the - in front > >>>>> of qt4 here? I only ask because it would seem that a > >>>>> single default-enable should suffice in lists like this > >>>>> to indicate a resolution path, no? That is, '^^ ( +flag1=20 > >>>>> -flag2 -flag3 -flag4 )' to me seems like it would be the=20 > >>>>> same as '^^ ( +flag1 flag2 flag3 flag4 )' > >>>>=20 > >>>> If the user has both "qt4 qt5", then enabling qt5 alone=20 > >>>> won't help to resolve "^^ ( qt5 qt4 )". > >>>>=20 > >>>=20 > >>> Right, but the PM knows based on a particular REQUIRED_USE=20 > >>> operator what it would need to do when a particular flag is > >>> set to default. Given '^^' is must-be-one-of, the +flag would > >>> be enabled and all the other flags would be disabled, right? > >>>=20 > >>> Here's how I'd see it mapping out: > >>>=20 > >>> || ( +flag1 flag2 ... ) , PM only forces-on flag1 ^^ ( > >>> +flag1 flag2 ... ) , PM forces-on flag1, forces-off all > >>> others ?? ( +flag2 flag2 ... ) , PM forces off all but flag1 > >>>=20 > >>> I'm not sure if the following make sense though... thoughts? > >>>=20 > >>> {,!}flag1? ( +flag2 ) , PM forces-on flag2 {,!}flag1? ( > >>> +!flag2 ) , PM forces !flag2, meaning forces-off flag2 > >>>=20 > >>>=20 > >>> I'm just wondering if it's really necessary in terms of > >>> syntax to specify the flag-negation that the PM would need to > >>> do. > >=20 > >=20 > >> See my other email: neither + nor - are necessary :) > >=20 > >=20 > >=20 > >=20 > > I'd disagree on that -- technically they aren't necessary, but > > the whole reason why these new operators were added in the first > > place was so that it's a lot easier for developers to fill in > > REQUIRED_USE and get the logic right. Mapping out a ^^ ( flag1 > > flag2 flag3 flag4 ) into all of its permissible flag-a? ( flagb > > !flagc !flagd ) variants is a royal pain. Plus there's=20 > > readability/understandability to consider here. > >=20 >=20 > err, flaga? ( !flagb !flagc !flagd ) i mean.. It is indeed longer (n flags to roughly n=C2=B2 flags expanded i'd say), but i disagree on the readability: i find it much more readable as "if flaga is enabled then flagb, flagc and flagd must be disabled" etc. which express clearly the preference than "exactly one of flaga flagb flagc flagd except if there is a problem then flaga but not the others". Also, there's something we've overseen with the +/- syntax: What about "^^ ( +flaga -flagb -flagc -flagd )" with USE=3D"-flaga flagb flagc" ? The only way to solve it would be USE=3D"flaga -flagb -flagc" while the "implication syntax" could give you USE=3D"-flaga flagb -flagc" (or any other preference of the ebuild writer). Finally, about getting the logic right, since it's a subset of the current syntax I don't think that should be a problem :) Alexis.