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 2A310139694 for ; Wed, 31 May 2017 19:02:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2DF6DE0EC1; Wed, 31 May 2017 19:02:38 +0000 (UTC) Received: from smtp.gentoo.org (dev.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 C9F60E0EB7 for ; Wed, 31 May 2017 19:02:37 +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 06960341718; Wed, 31 May 2017 19:02:35 +0000 (UTC) Message-ID: <1496257344.25758.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: Wed, 31 May 2017 21:02:24 +0200 In-Reply-To: <20170531193922.477245bb@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> <1496167898.1335.1.camel@gentoo.org> <20170530204614.61e8e42c@gentoo.org> <1496213717.1164.1.camel@gentoo.org> <20170531093257.23b66f88@gentoo.org> <1496217792.1164.5.camel@gentoo.org> <20170531103819.417c2420@gentoo.org> <1496235892.25038.1.camel@gentoo.org> <20170531193922.477245bb@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-U1DMakxWR1f71q372DLO" 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: 903e72ae-bfe2-44c9-99e0-c67addf66320 X-Archives-Hash: 7607327ed645d4a5143acd9f39b6890e --=-U1DMakxWR1f71q372DLO Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On =C5=9Bro, 2017-05-31 at 19:39 +0200, Alexis Ballier wrote: > > > Again, you *need* to process the constraints in order. '!a? > > > ( b ) !b? ( a )' is not deterministic when none of a and b are > > > enabled otherwise. =20 > >=20 > > You can't rely on any particular order of constraints, especially when > > eclass stacking comes into play. You could try defining some > > constraint- sorting algorithm but it's going to be complex and it's > > usefulness will be limited anyway due to various kinds of grouping. >=20 >=20 > Better have some order: If half of the above constraint comes from > ebuild and the other half comes from eclass, then PM might toggle 'a' or > 'b' depending on the phase of the moon which is specifically what we're > trying to avoid. No, it can't. That's the whole point. The algorithm must be defined so that it is always predictable independently of order (maybe except the ordering inside ^^, ||, ??) and independently of how it's nested (i.e. 'a? ( b? ( c ) )' must give the same result as 'b? ( a? ( c ) )'). If you start relying on stuff like ordering, you're one step from making stuff suddenly fail or change meaning due to minor changes, like sorting stuff. > eclass stacking is not a problem: specify if it's append or prepend and > be done. What about multiple inherits with guards? Next thing I know, we end up putting REQUIRED_USE outside guards (like we have to do with EXPORT_FUNCTIONS now) because you need a specific order, and guards make it unpredictable. > Note that if you want to remove the need for an order, you'll need to > ensure that all orderings of the constraints give the same result. It's > not sufficient to "only" check all possible inputs. That's the matter of the algorithm. > Also, what happens if we applied all the constraints and obtained some > useflags setting that still fails REQUIRED_USE check ? It can't happen. If you can apply all the constraints, then implicitly REQUIRED_USE is satisfied. If you can't apply all the constraints, then it just fails. Of course, we want to ultimately avoid that case. > > The point would be: by definition, the solver should be able to touch > > *any* USE flag. If it can't, it mostly implies that you can't use > > the automatic solver, and so the case is irrelevant for checking. > > Attempting to go beyond that is going to give a lot of complexity > > and most likely kill the whole idea. > >=20 > > One thing we need to worry about are masks. We need to think about > > them. >=20 > It makes zero difference for any solver if you replace variables > (useflags) by 'true' or 'false' constants (masked/forced/user-forced > useflags). It's even simpler actually. Whether the formula is not > constantly 'true' (ie REQUIRED_USE is useless) or constantly > 'false' (ie there's no way to solve it) is equivalent to solving SAT. > We likely don't want that for repoman running on php. >=20 Well, probably yes. We just need to make sure to apply them correctly in different contexts, to avoid accidentally skipping some constraints. I think it would be reasonably to assume that: a. flags masked/forced on LHS of implications (foo?) are evaluated in place, i.e. either always require RHS or remove it completely: foo? ( bar ) -> with foo forced, bar is always required =3D> we should also force bar b. flags masked/forced inside ^^, ??, || alter the contents/meaning -- in particular they might replace the whole construct with a single flag or make it unsolvable: ^^ ( foo bar baz ) -> with foo forced, [bar baz] are never allowed =3D> we should mask them || ( foo bar baz ) -> with foo forced, the constraint can be skipped c. flags masked/forced otherwise can't be altered: foo? ( bar ) -> with bar forced, we can skip the constraint. -> with bar masked, foo should be masked as well Does that cover all the contexts? --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-U1DMakxWR1f71q372DLO 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+0Rk4FAlkvE0BfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZE QkIwN0NDNEYwREFEMDZFQTBBRkU0MUIwN0ExQUVBRUZCNDQ2NEUSHG1nb3JueUBn ZW50b28ub3JnAAoJELB6GurvtEZOu3sQAIdWYNYEDgFASQjIUYJp17iVqV/BUsye lqoITQ1ITZPqjg3v0tAKfnitRYq+bRfBlv8/kQ3rOl7Gtsevffy5HCmnIt7BS4RM tEieaJ153omtCEPTHsZF0FZgXRj/m6S6/g0wajq1mWrQZnn2fIcZglaNzdoc5t02 7PpPL7vGGzNQCZLUVPlbNESZGRbh7YjiHBNDeM9Bej2X58FSt8cXLtXF5RiIcRAq /GWIEw5tM/aKcaoPNG3R6/E5AqOY3fF1t8npX4qZCAAdI02Zq9A+LnCd5/bn8LWX o+AEwnuEG/O74F2o6+QRKKVfqVntkhy4Mkz2bUpVFq+cRc9inZ6B/zFhQEgFTOGa U80oM3Q7Wymv2byIum23KPATs5qlLBwJQIhYo5mm+JZSrGCaiEGeNnrYQIg4/GUZ pn0gTRNgTPln6ZJUU7SIOryul5kY7KXWJTUCwHypb2XghNxa2IWE/HvlVc8cjJOQ WbBDxBlAidGZCZ/nFf0jyIB4rO97MV+iLU6xKp7105BeITQ0uhaabXmZfWdH1RYV O0KQ8Hs5YvmwRwERFKtovYU9TeAVc0UGA8fcYLtfGl4jwQxkOCf8y1iXeyb60CEH 7MMsaUkrk90E7zy0pXPJ++VnungdtD5KZuYzLJeJYLlvQ+zO9VX6Mi0qZ0q2U1n4 y7QYNodHITRP =vciW -----END PGP SIGNATURE----- --=-U1DMakxWR1f71q372DLO--