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 C489A139694 for ; Wed, 14 Jun 2017 09:07:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3BC8221C08C; Wed, 14 Jun 2017 09:07:09 +0000 (UTC) Received: from smtp.gentoo.org (smtp.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 D6CE4E0B73 for ; Wed, 14 Jun 2017 09:07:08 +0000 (UTC) Received: from localhost (unknown [IPv6:2a01:e34:eeaa:6bd0:4ecc:6aff:fe03:1cfc]) (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 C8890341887 for ; Wed, 14 Jun 2017 09:07:06 +0000 (UTC) Date: Wed, 14 Jun 2017 11:06:59 +0200 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE) Message-ID: <20170614110659.6bf4d1c2@gentoo.org> In-Reply-To: <1497392022.29918.1.camel@gentoo.org> References: <1496071993.31087.1.camel@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> <1496671825.1230.3.camel@gentoo.org> <20170605192433.6238797b@gentoo.org> <1496686212.1222.4.camel@gentoo.org> <20170606140803.051f8048@gentoo.org> <1496770744.1157.1.camel@gentoo.org> <20170607101759.7e21f0f6@gentoo.org> <1496827679.2129.3.camel@gentoo.org> <20170607115654.2a5da5e2@gentoo.org> <1496999960.29391.1.camel@gentoo.org> <20170609134110.418ae6ac@gentoo.org> <1497012847.25475.4.camel@gentoo.org> <20170609161619.1b72ad5b@gentoo.org> <1497025310.25475.7.camel@gentoo.org> <20170611180518.5e28ddfa@gentoo.org> <20170612110836.7b670c93@gentoo.org> <1497295036.1575.10.camel@gentoo.org> <20170613122745.455b39f7@gentoo.org> <1497392022.29918.1.camel@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; 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: c78ab02f-1297-42b4-ac3e-9007918b75f4 X-Archives-Hash: 7695c40e42ca2fe86c1ae9db61e74c12 On Wed, 14 Jun 2017 00:13:42 +0200 Micha=C5=82 G=C3=B3rny wrote: > On wto, 2017-06-13 at 12:27 +0200, Alexis Ballier wrote: > > On Mon, 12 Jun 2017 21:17:16 +0200 > > Micha=C5=82 G=C3=B3rny wrote: > > =20 > > > I've actually started typing the initial specification yesterday > > > [1]. As you can see, banning the extra constraints has made the > > > algorithms much simpler. In particular: > > >=20 > > > 1. You do not have to define 'falsify' for anything other than > > > pure flags -- which makes it easy to inline it. > > >=20 > > > 2. ||, ??, ^^ groups are only flat lists of flags -- which makes > > > reordering and processing them trivial. > > >=20 > > > 3. The algorithm is recursive only on USE-conditional groups. This > > > makes it trivial to make it iterative. Optimizations become > > > trivially possible. =20 > >=20 > >=20 > > While you're right in one sense, you're mixing two different things > > here. What you wrote *is* recursive. It does not recurse just > > because you're assuming a restricted syntax. You're only saving two > > things: you don't need to define how to enforce to false (that is 3 > > lines not 3 pages :=3D) ) and you're avoiding the nested use > > conditionals that are already ill defined per the current spec > > (foo? bar is equivalent to && ( foo bar ) when nested) which I > > believe is already another problem. > >=20 > > Then, remember how I wanted to be much more drastic than you in the > > beginning by killing all ||,&&,^^ etc. and keep only use > > conditionals in REQUIRED_USE ? Well, that's where the complexity > > comes. The whole deal then is to define rewriting rules for the AST > > so that the algorithm you describe executes the exact same > > instructions but the new AST only has use conditionals. This is > > more like writing a compiler for the spec, so this does not belong > > to the spec and there is no issue here. =20 >=20 > I'm looking for a compromise here. Killing those groups completely is > going to make things harder for users. Keeping them with functionality > limited to what's used in ~99.9% ebuilds (based on your numbers) is > IMO a better choice. I already said I see the limited syntax as a good thing because it forces devs to write constraints that have a natural interpretation in how it is solved. However, you can't limit the syntax without a new EAPI, and more importantly, properly solving does not even require limiting the syntax. BTW, I don't know how you get that info from my data because I never voluntarily checked for a restricted syntax :) > > [BTW: checking the rewrite rules behave properly is what I meant by > > rebasing solve() on top of it and being happy with it] =20 >=20 > Could you reiterate the current solving rules=C2=A0(trueify/falsify)? Are > they equal to the ones you listed last, or does the current > implementation change anything? Let's recap a bit. nsolve() is poorly named and does not solve anything. It translates to implications and checks whether the implications solver will always provide a valid result in one pass. So, if you only care about solving rules, read your spec man. For the more general case it should behave like those trueify/falsify with the change that nested implications are interpreted as && (so no more !(a -> b) crap to worry about). If you take solve() as an implementation of your spec, you have: solve(x) <=3D> solve(to_impl.convert_to_implications(x)) when solve(x) is defined; with the added benefit that 'solve(to_impl.convert_to_implications(x))' is defined and should provide proper results on the whole REQUIRED_USE syntax as currently defined (granted that nsolve(x) does not report anything wrong). > > > Nevertheless, feel free to play with the full implementation. If > > > you're interested, you can play with the complex cases more. In > > > particular, I'm wondering whether nsolve will actually consider > > > most of them solvable. > > >=20 > > > As for the results, I think it is the point where we start > > > preparing pull requests with REQUIRED_USE changes to see whether > > > the developers agree with such changes. =20 > >=20 > > If by that you also include code cleanup and writing tests then > > yes :) =20 >=20 > I'm not sure if we're talking about the same thing. I'm talking about > filing pull requests against ebuilds whose REQUIRED_USE is rejected by > nsolve. I think it'd serve as a reasonable field test for whether > developers agree with the imposed restrictions. I was talking about PRs against portage & repoman. > > > [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:ReqUse =20 > >=20 > > I really don't like the reordering thing. Even the restricted > > syntax does not fix the issue with '^^ ( a b ) b? ( a )' already > > mentioned here. It'd be much better and simpler for the spec just to > > assign a fixed value and use the solving rules with those. =20 >=20 > You're not going to convince me by providing examples that are utterly > broken by design and meaningless ;-). Well... if it's so obvious that the example is broken by design that you don't even bother to explain why, I assume you have an algorithm for that. Where is the code ? What are the numbers ? How many ebuilds might fail after reordering ? How can this be improved ? Extra question: Is there *really* a point in pushing user preferences that way, esp. when developers can write '!b? ( a )' instead of '|| ( a b )' and just kill any possibility of changing the order ? As for a real world example, I'll let you find some more interesting ones, but this one will probably be interesting to you and is a good start: app-text/wklej-0.2.1-r1 ^^ ( python_single_target_pypy python_single_target_pypy3 python_single_target_python2_7 python_single_target_python3_4 python_single_target_python3_5 python_single_target_python3_6 ) python_single_target_pypy? ( python_targets_pypy ) python_single_target_pypy3? ( python_targets_pypy3 ) python_single_target_python2_7? ( python_targets_python2_7 ) python_single_target_python3_4? ( python_targets_python3_4 ) python_single_target_python3_5? ( python_targets_python3_5 ) python_single_target_python3_6? ( python_targets_python3_6 ) vim? ( ^^ ( python_single_target_python2_7 ) ) Hint: It loops as written here. Reordering the ^^ in a proper way makes it solvable. Putting the 'vim? ( ... )' part first makes it solvable in one pass. Extra bonus: If your algorithm solves that in reasonable time, run it again as if PYTHON_COMPAT also contained 'python3_{7,8,9,10,11,12}' Alexis.