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 B7D39139694 for ; Tue, 30 May 2017 18:12:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F071621C185; Tue, 30 May 2017 18:11:51 +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 9F54821C17B for ; Tue, 30 May 2017 18:11:51 +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 2C204341723; Tue, 30 May 2017 18:11:49 +0000 (UTC) Message-ID: <1496167898.1335.1.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: Tue, 30 May 2017 20:11:38 +0200 In-Reply-To: <20170530173340.0b575526@gentoo.org> References: <1496071993.31087.1.camel@gentoo.org> <20170529200037.2559f80a@gentoo.org> <1496093035.12795.3.camel@gentoo.org> <20170530094245.40e1cf64@gentoo.org> <20170530092245.681d4aeb@snowblower> <20170530104654.31b89e10@gentoo.org> <20170530095607.1adbc0b8@snowblower> <20170530112518.65b4f9e9@gentoo.org> <22829.24276.295.969060@a1i15.kph.uni-mainz.de> <1496154812.1238.5.camel@gentoo.org> <20170530173340.0b575526@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-8tGJPB+uuO4qcFgUBCgI" 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: 3a3f5916-add8-4d7c-ba8f-c8837a3e4268 X-Archives-Hash: 3705ab76467173c7a41644d5963e9cea --=-8tGJPB+uuO4qcFgUBCgI Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On wto, 2017-05-30 at 17:33 +0200, Alexis Ballier wrote: > On Tue, 30 May 2017 16:33:32 +0200 > Micha=C5=82 G=C3=B3rny wrote: >=20 > [...] > > The problem is: how far is that going to work? That's what I would > > like to try determining in the first place. > >=20 > > I'm most worried about complex constructs like: > >=20 > > foo? ( bar ) ^^ ( baz=C2=A0bar ) >=20 > The order in which it is written will matter: > Assuming user has enabled 'foo', first process 'foo? ( bar )', which > gives you "USE=3D'foo bar'". Then process '^^ ( baz=C2=A0bar )'; all good= , > we're done. >=20 > If user has enabled 'foo baz' then there is a problem and it is > normal to rant. >=20 > > But I do not have any obvious ideas how to express them safely while > > preserving readability and relative simplicity of the constructs, i.e. > > not having to write a big mapping table. > >=20 > > Especially if we are to allow having a preference on baz, the mapping > > for ^^ alone would be: > >=20 > > !bar !baz -> !bar baz > > bar !baz -> bar !baz [valid] > > !bar baz -> !bar baz [valid] > > bar baz -> !bar baz > >=20 > > With the additional foo constraint, it becomes harder but not > > impossible. However, with more constraints we may reach a dead end. >=20 > You already made a convincing argument that || & co are good things to > have, that's not to write the combinatorics of the whole thing as > implications! >=20 > Moreover, you can use implications and the processing order as hints: If > you believe 'if foo and bar are enabled then baz should most likely be > enabled even if the latter '|| ( bay baz )' would select 'bay' and not > 'baz'' you prepend required_use by 'foo? bar? baz' and are done with it. >=20 >=20 > > Of course, we could just validate all the possible cases via repoman, > > and reject the ebuild if there's at least one conflict between them. > > Not sure how to express that properly in the spec though. Not sure > > how it would work practically. >=20 > Adding a 2^n check to repoman isn't gonna work well. >=20 I'm not saying it's the most optimal algorithm of verifying the correctness of the constraints. It's just the one that's quite obvious -- relatively simple and reliable. If someone can come up with something better that covers at least the most common cases, I'm all for it. That said, this wouldn't be that much of a problem if we can keep the n low. For a start, we can rule out all flags that don't appear in REQUIRED_USE at all. Furthermore, I think we could also ignore the constraints for flags that don't appear there at least 'twice', and so on. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-8tGJPB+uuO4qcFgUBCgI 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+0Rk4FAlkttdpfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZE QkIwN0NDNEYwREFEMDZFQTBBRkU0MUIwN0ExQUVBRUZCNDQ2NEUSHG1nb3JueUBn ZW50b28ub3JnAAoJELB6GurvtEZOvJYQAJ4P21TSRnWfhsJeQ2aslOL+3H7533U8 J+e5Vjys7OM2zuFfp7EIU3WJegn0A8j/49kfHVBBA0H4ubrrQ1NMmMCPqvrGaNqr 88wdv8VoCqfz//2lL3g/MulLS/EW9xzLPo1WxvSaFzvemB011kvh7JoW3mQLlb9v Ths1TEXPOnhC7sYbqlwPHcbrbXDG/D9gvsOkZOOOEIaCdID1QmCpbJJiSmYUIm/0 SJgc7OSCfq/t6XsGd3PvxjlUdNtOpAHqF9FEUciDGcPPXFXQ8Tkt9WGMsi0jhQhs 7dOWK/1oEBWKD5bwu3GyTIDvyk2IKODF6JnXaV4BGbLyRbV15SleQAShcQYAkXqs Qfu84A2JM3jbEQ3VqnuuwqbInpOEcL9CwpuV1lKCQGFPhMHT+EbVHTkrT3WrhY+/ FfJtb+IzSb9G99oc3kT/xcCtsuur53kIWMHHHbS2dxF6wckyF3JY/1bu3B9Uon5z LwPoX2W979ajp/WUFLHRagI8slLVX3WFTsZXqsPcci9ZcQ8zrZ1lp6aNorXyl5pQ y2BJM4ce/IxDuS98cC5Z4cEJQvIf3MWMu9tsY33lJJdfHT7UEJ5OIHCg1rjtQmc4 fIzmhOK8IMLqKc4TL3asHOL1kB+cWyvga6vrzYq9qEE/ZgWG+BIGL+5dHYk9viOn Kdu78XIfa/rA =267J -----END PGP SIGNATURE----- --=-8tGJPB+uuO4qcFgUBCgI--