From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 8EAF3139694 for ; Mon, 29 May 2017 21:24:10 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 961FAE0D1F; Mon, 29 May 2017 21:24:01 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 31D3EE0C56 for ; Mon, 29 May 2017 21:24:01 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 70C5B3416E0; Mon, 29 May 2017 21:23:59 +0000 (UTC) Message-ID: <1496093035.12795.3.camel@gentoo.org> Subject: Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE) From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Mon, 29 May 2017 23:23:55 +0200 In-Reply-To: <20170529200037.2559f80a@gentoo.org> References: <1496071993.31087.1.camel@gentoo.org> <20170529200037.2559f80a@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-8QdTmRZ4Ih2gfpEhNwcr" X-Mailer: Evolution 3.22.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 X-Archives-Salt: cd654501-0a6c-4791-86e9-e9df7b3350d2 X-Archives-Hash: cfaeb94c754b848444546f19194292c9 --=-8QdTmRZ4Ih2gfpEhNwcr Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On pon, 2017-05-29 at 20:00 +0200, Alexis Ballier wrote: > On Mon, 29 May 2017 17:33:13 +0200 > Micha=C5=82 G=C3=B3rny wrote: >=20 > > In the basic form, it can be used to conditionally force a specific > > flag to be enabled or disabled. For example: > >=20 > > foo? ( bar ) > >=20 > > would mean that the bar flag is implicitly enabled (forced) if foo is > > enabled as well. Appropriately: > >=20 > > foo? ( !bar ) > >=20 > > would mean that the bar flag is implicitly disabled (masked) in that > > case. >=20 > All good here. >=20 >=20 > > It can also be used with multi-flag ??, ^^ and || constraints, i.e.: > >=20 > > - ?? means that at most one of the flags can be enabled. If user > > configuration causes more than one of the flags to be enabled, > > additional flags are implicitly disabled (masked) to satisfy > > the constraint. > >=20 > > - || means that at least one of the flags must be enabled. If user > > configuration causes none of the flags to be enabled, one of them is > > enabled implicitly (forced). > >=20 > > - ^^ means that exactly one of the flags must be enabled. The behavior > > is a combination of both above constraints. > >=20 > > The automated solving of USE constraints would require the developers > > to consider the implicit effect of the constraints they are writing. >=20 >=20 > Can you provide an efficient algorithm for the above syntax? > That is, given a set of +/- useflags forced by user, output the set of > effective useflags (or a rant if it is inconsistent). I'd rather leave that to people who are good with algorithms. I find the whole thing scary but I don't really see a sane alternative here. Worst case, we have to figure out some arbitrary limitations to keep things sane. > Maybe I'm mistaken, but I doubt it is possible with n-ary constraints. >=20 > Now the extra question: Do those n-ary operators have any advantage ? Yes, they do. They improve readability, compared to cascades of plain constraints. I'm pretty sure users will be happier to see 'you need to select one of foo, bar, baz' than 'if foo is disabled, then ...' > The point is to express some preference, below you suggest to leave > that to the user, but what about leaving that to the ebuild developer? Well, I don't find that a killer feature but I don't see a reason to take it away either. Either way we have some risks, especially when USE dependencies and blockers are involved. In both scenarios, I find it less risky to let user control the order than to rely on all developers respecting the same preference order. Not saying the latter wouldn't hurt anyway but the users would at least have an easy way out. > That way, e.g., || can be rewritten as implications: '|| ( a b c )' > becomes '!b? !c? a' meaning if none is enabled then a is automatically > enabled. Unless you are planning to cache the rewritten forms, I don't see a problem, really. You just reorder the flags according to the apparent preference before rewriting. >=20 > Note that with only unary constraints, computing the set of effective > useflags becomes trivial (linear in the # of useflags + constraints): > take the constraints as a list, solve the first one, add its > consequences (if any) to the set of forced useflags, continue with next > constraint or rant if the set of forced flags is inconsistent. Sounds fine. But I'm not an expert to really judge that ;-). --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-8QdTmRZ4Ih2gfpEhNwcr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQKmBAABCgCQFiEEbbsHzE8NrQbqCv5BsHoa6u+0Rk4FAlkskWtfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZE QkIwN0NDNEYwREFEMDZFQTBBRkU0MUIwN0ExQUVBRUZCNDQ2NEUSHG1nb3JueUBn ZW50b28ub3JnAAoJELB6GurvtEZONYYP/R5u81HMVKLfoQYXNZkrsc95DGcg/WN2 D4tyCimOnJb/HJRB1I3V5Op+tmdSXD0HZhEoUrz12ZD/b9ueK9eDuQRyDX2DI9ei o25C9royBqExT6oMCE8k0oz9+9eWkf8JMmgAm2ceCo1Y1+WAtkF8qZHVJ0tg8ykp gKV5fHHMiQ98lzZk7H+K7+7P2T3iCwsf/2y6J0f1gxyaXRHnoIIiKNtVVWLDable SHR2QJNU5A88NLKnYeDR04gwxprsCDn4tCVfL7VDFZ7KbXLwqhq2UzfM1ZkfoEU9 ZlEZjmaXZrhf78YxirPmSmLZTyDfNJZ0KKsImILdv260PQ/RWt3+q/XebmE9BPw9 8b+dC1A3TWhS57iMruvTEjMCE6UEHvi7DHqaD+9U2uXB5xWAKMlG/9vdz+eGm8vs 49yhJV3IbvsGvWemBwzlz+9RcpX32MYoChcPXhXX27oYySY4kqJBPLFdHMU9bvv1 vwvSiVdhxTr9rPhujix9pbBCzSpR1utX5BPYLf+4eSWhc+F45zsrsaVkiPGVBkUj 7P8TutFHzBm5dCwKNMHv/RGzRuXy3nFLtWRpShKlrakzeE9hr8vuwVptuz3lbmfd W9KwdG18NH2EtwsPkf1FMCkjbuAFe89WBZ30Yimepu/SZfn/1CV43UWcwbFirNJv AosS8jhYKrfu =yjY5 -----END PGP SIGNATURE----- --=-8QdTmRZ4Ih2gfpEhNwcr--