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 A94E6139694 for ; Mon, 5 Jun 2017 14:10:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CF98821C07C; Mon, 5 Jun 2017 14:10:31 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.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 785E9E0E67 for ; Mon, 5 Jun 2017 14:10:31 +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 A6D563416D2; Mon, 5 Jun 2017 14:10:29 +0000 (UTC) Message-ID: <1496671825.1230.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, 05 Jun 2017 16:10:25 +0200 In-Reply-To: <20170605095516.0b463432@gentoo.org> References: <1496071993.31087.1.camel@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> <1496257344.25758.1.camel@gentoo.org> <20170601105523.08a9234e@gentoo.org> <1496352685.30502.4.camel@gentoo.org> <20170602132758.50a5f734@gentoo.org> <1496411717.29233.5.camel@gentoo.org> <20170603130000.4f88fb14@gentoo.org> <1496503989.15351.1.camel@gentoo.org> <20170603185835.57741ff0@gentoo.org> <20170604105938.2b40157f@gentoo.org> <20170605095516.0b463432@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-LJRkizszr7howGBUfyxj" 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: 04e53bf1-0f9a-4847-b550-31fafe504b77 X-Archives-Hash: c47fea4ba3edd331f977dffae40348fe --=-LJRkizszr7howGBUfyxj Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On pon, 2017-06-05 at 09:55 +0200, Alexis Ballier wrote: > On Sun, 4 Jun 2017 10:59:38 +0200 > Alexis Ballier wrote: >=20 > > Here's a quick n dirty code to play with, based on yours:=20 > > https://github.com/aballier/required-use >=20 > I've run that on the whole tree (considering all ebuilds with non > empty REQUIRED_USE), some stats: >=20 > $ time python3 classify.py requsel=20 > Stats: > Parse error: 16 Hmm, how did you get those numbers? I just tested parsing and found only 7 unique REQUIRED_USE entries that fail. However, my sample file is only around 1000 entries long, so either I failed to get all of them, or you didn't deduplicate your list ;-). More on it below. > Good: 8316 > Need topo sort: 140 > Cyclic: 57 >=20 > real 0m2.996s > user 0m2.950s > sys 0m0.004s >=20 >=20 > Running time is good I think. > Parse error is some nested construct not supported by your parser that > I have not fixed either. Yes, the time is great. It means we can actually think about integrating it with repoman/pkgcheck. > The cycle is mostly due to: > $ python3 nsolve.py 'llvm? ( gallium ) gallium? ( llvm )' > [...] > toposort.CircularDependencyError: Circular dependencies exist among > these items: {[gallium]? =3D> [llvm]:{[llvm]? =3D> [gallium]}, [llvm]? = =3D> > [gallium]:{[gallium]? =3D> [llvm]}} >=20 >=20 > This is something I had overseen when replacing 'a q'_j is some p_i and > one of q_1 ... q_m might be false' by only 'a q'_j is some p_i'; it can > be replaced without changing anything in the way PM would solve it by > "a q'_j is some p_i and the set of {q_j} is not a subset of q' union > p'" (that is, {q_i} is not trivially true if the 2nd clause is > applied). Extending that, we get those stats: I'm not even trying to understand the things you say with indexes but I trust you know what you're doing. For completeness, we need to consider three cross-dependent states: a. a? ( b ) b? ( a ) i.e.: y_1 =3D y_2 =3D x_1 v x_2 iow, enabling either of the flags causes both of them being enabled. I'm not sure if we have a valid use case to keep such flags long-term but short-term they could be useful to handle transition periods when upstream merges two features (or makes them cross-dependent) and we want to preserve compatibility with split flags. b. !a? ( !b ) !b? ( !a ) i.e.: y_1 =3D y_2 =3D x_1 ^ x_2 iow, you have to enable both flags to keep them enabled. Not sure if we have any valid use case for this. c. a? ( b ) !a? ( !b ) i.e. y_1 =3D y_2 =3D x_1 This mostly a reduced result of: a? ( || ( b c d ... ) ) !a? ( !b !c !d ... ) [NB: it would be useful to have a short syntax for that] I suspect this will be commonly useful to express provider dependencies, i.e. enforcing a particular constraint for providers only when the feature flag is enabled, and disabling all provider flags when it is not. FWICS, my version solves all three cases correctly, and your does not explode on them. > I'll let you play with it, but for me it seems this would work quite > nicely. >=20 Well, I guess it's time to hit the next level. For a start, we have to handle all-of groups, i.e.: ( a b c ) Stand-alone makes little sense (and little trouble) but as you could have seen it's used nested in other thingies: 1. || ( ( a b ) ( c d ) e ) 2. ?? ( ( a b ) ( c d ) e ) 3. ^^ ( ( a b ) ( c d ) e ) For verifying constraints, they are not bad. We just follow the generic rule that the branch evaluates to true if all subexpressions are true.=C2= =A0 For solving, it might be a little unclear on how to proceed with partially true branches but for the sake of simplicity I would just ignore them and behave as if they were false. That is, case (1) with USE=3D'c' would result in 'a b' being enabled. The practical uses I've seen are: a.=C2=A0|| ( deprecated ( gtk3 introspection ) ) I guess this one would be equivalent to: !gtk3? ( !introspection? ( deprecated ) ) b. ^^ ( ( !32bit 64bit ) ( 32bit !64bit ) ( 32bit 64bit ) ) This looks like a crazy way of saying: || ( 32bit 64bit ) c. ^^ ( ( !ruby !s7 ) ( ruby !s7 ) ( !ruby s7 ) ) This looks like an insane version of: ?? ( ruby s7 ) except that per my solver it just disables both when both are set ;-). Not sure if the extra complexity is worth for roughly one valid use case, and a lot of insanity. I've pushed a simple update to my parser to account for this. However, it doesn't support replace_nary atm, so it won't work for you. Of course past that there's a deeper insanity: all those constructs can be nested without limits. Verification is possible, solving maybe -- but I'm not sure if we even want to try to think what the correct solution would be. There's only one use of this: ?? ( gl3plus ( || ( gles2 gles3 ) ) ) FWICS, it probably works like this; =C2=A0g=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0g=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0l=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0l=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A03 g g=C2=A0=C2=A0=C2=A03 g g =C2=A0p l l=C2=A0=C2=A0=C2=A0p l l =C2=A0l e e=C2=A0=C2=A0=C2=A0l e e =C2=A0u s s=C2=A0=C2=A0=C2=A0u s s =C2=A0s 2 3 | s 2 3 =C2=A00 0 0 | 0 0 0 (=3D=3D) =C2=A00 0 1 | 0 0 1 (=3D=3D) =C2=A00 1 0 | 0 1 0 (=3D=3D) =C2=A00 1 1 | 0 1 1 (=3D=3D) =C2=A01 0 0 | 1 0 0 (=3D=3D) =C2=A01 0 1 | 1 0 1 [unsolvable due to loop] =C2=A01 1 0 | 1 1 0 [unsolvable due to loop] =C2=A01 1 1 | 1 1 1 [unsolvable due to loop] i.e. it would be equivalent to: gl3plus? ( !gles2 !gles3 ) unless the author meant something else and failed. The question is whether we want to: a. actually try to solve this nesting insanity, b. declare it unsupported and throw REQUIRED_USE mismatch on user, c. ban it altogether. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-LJRkizszr7howGBUfyxj 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+0Rk4FAlk1ZlFfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZE QkIwN0NDNEYwREFEMDZFQTBBRkU0MUIwN0ExQUVBRUZCNDQ2NEUSHG1nb3JueUBn ZW50b28ub3JnAAoJELB6GurvtEZOcnMQANbtVFU0u4P8slLYZhifIC2TnmSOtcfk VPgQO1Ugu/GbTzyqu7Bqjw66xVywC7sYM051NxgPBYLcmXwoJNtAz+HUGP0U+izR Ge52q0aj8Lbmtqh+jV/PeOcHG88KfoohxzJT1Qo18Bpn0yAIlw/nDM+NTxGu8d7u WSXXxZ7c56p9bl810WiPEwg9/V08VofxNiYuWhVaU5tgjcMkjSH3NV6ONvahUl3F 2R2kj387I5bjc4WxMmW9qaQXOwAewdLNsV7pDz0ge3aKLECqooyiPJxrzTdccdcc a+PnzURXd8XJJrtKXrtORg1GBRp8GoOjvBycEe0FjmCqpmgUX9N52/3y0cL+u0II gHSQxSP+wdXh5Uak27W5Z87J1T6GMrkpM05l2t9K93XHz7AntvktSDTCSAgnPDCB lBrMcZXww9vnroDnNhrLvsumtDDpJNiF7SFyM0khxx1ISPM0lxK0NfHuFs236JRB WWt5OHJTWi+NQ0bdQ/Xws+90RBZvO6hDY/T4jdq+Vq/Jhn8zlE0C1xu8dsXZWrKx DwaZqDNMVUTw11kZABRaS1zGixm3+CI+aeN4HhoIY5aukiC0TbiiVOCbr9chSmKQ 1/4GiJRbyVqT8mV1VMIla7taiQWas4xPev2CAP9EeCU1k0Mf8KQXx9Fzg0z7bZ0I KFi6A/a12quT =43z0 -----END PGP SIGNATURE----- --=-LJRkizszr7howGBUfyxj--