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 3E52F139694 for ; Tue, 30 May 2017 08:30:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0463FE0F4F; Tue, 30 May 2017 08:29:55 +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 9BD13E0EF1 for ; Tue, 30 May 2017 08:29:54 +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 F25AD33BEAE; Tue, 30 May 2017 08:29:52 +0000 (UTC) Message-ID: <1496132988.1617.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: Tue, 30 May 2017 10:29:48 +0200 In-Reply-To: <20170530094245.40e1cf64@gentoo.org> References: <1496071993.31087.1.camel@gentoo.org> <20170529200037.2559f80a@gentoo.org> <1496093035.12795.3.camel@gentoo.org> <20170530094245.40e1cf64@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-Tq4OlBpya5VXQpdBn4hy" 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: 8082b175-b493-496e-9531-e9db54a7f74a X-Archives-Hash: a06bc63f0947d7891710c2e0739a85ff --=-Tq4OlBpya5VXQpdBn4hy Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On wto, 2017-05-30 at 09:42 +0200, Alexis Ballier wrote: > On Mon, 29 May 2017 23:23:55 +0200 > Micha=C5=82 G=C3=B3rny wrote: >=20 > > 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 > [...] > > > > 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 > > >=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). =20 > >=20 > > 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. >=20 > Well, Ciaran is a bit extreme with his implementation thing, but > he's right in the sense that here you're really repeating the same > mistakes that you're trying to fix. REQUIRED_USE was invented the same > way: Let's add some nice syntax to express dependency between useflags. > Ship it. Oh crap, this requires to solve SAT. Well, nothing good can be > done here, let's spit out to the user to chose for herself. > With your proposal, it seems to me you're simply postponing the problem > but not fixing it: Instead of spiting that one has to enable some > useflags, you'd spit that one has to specify how to solve the > constraint by expressing some preference. In the end, this'll add > another layer of complexity in both PM and the user configuration but > would not solve the root of the problem which is that no-one knows how > to automatically find a solution to those constraints and PM can't take > any action without user input. >=20 > You can't get away with "There is a solution but I'll leave that to > people who are good with algorithms": That is roughly the definition of > NP. If the person writing a proposal for a new feature (which is thus > supposedly the one person that has thoroughly thought the problem) can't > at least roughly draft how to implement it, that doesn't give much faith > in that it can be done properly. It certainly does not mean said person > is not good with algorithms but rather that the problem is very likely > to be a hard one. Not hard as in you need a Ph.D. in algorithms to > solve it but the kind of hardness almost every cryptographic algorithm > used today, and in the foreseeable future, relies on. That's why I'm sending this to the mailing list as a RFC, not a proposal to vote on. It solves a defined set of problems, and gives other chance to improve it and turn it into a complete solution. It's not like it's going anywhere before it's implemented as a PoC and tested. > > 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 ...' >=20 > If the point is to automatically propose a solution, then who cares > about readability? Users won't even see that message. But users should be able to reasonably figure out what happened, exactly. There's a difference in quality between the two messages: a. 'foo is enabled; bar, got disabled', b. 'one of foo, bar, baz had to be enabled =3D> you chose foo'. Not saying you can't figure it out. Saying in a more complex case, grouping constraints like this is helpful. >=20 > Note that there are plenty of ways to add determinism in your proposal, > but it *has* to be specified otherwise PM can't rely on it. For > instance, you can say that in an unsatisfied || block then the > left-most useflag is automatically enabled. || then becomes some > syntactic sugar around unary operators: || ( a ... ) becomes equivalent > to '!...? ( a )'. You can do the same for other operators. >=20 >=20 > Sidenote: I just realized '|| ( a b c )' with left-most preference might > be better since we are not dealing with binary variables but ternary > ones (user disabled, user enabled, unspecified). 'USE=3D"" || ( a b c )' > should evaluate to 'a', 'USE=3D"-a" || ( a b c )' should evaluate to 'b'. > I don't see how to rewrite that with pure implications. The ternary concept is not exactly in line with how we handle USE flags now. It's more like multi-layer binary. My proposal solved the problem you were trying to solve via establishing priorities -- I find it simpler to reorder the flags and use binary logic than to invent a more complex logic to solve the same problem. > > > 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? =20 > >=20 > > 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. >=20 > They already have an easy way out if you strip that part out of your > proposal: emerge will show some automatically enabled useflags; users > will notice and will fill package.use to disable the automatically > enabled useflag if they don't want it. >=20 > > > 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. =20 > >=20 > > 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 > It's not a problem of rewriting or caching the result but a problem of > having a deterministic way to auto-enable required useflags. >=20 > Bests, >=20 > Alexis. >=20 --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-Tq4OlBpya5VXQpdBn4hy 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+0Rk4FAlktLX1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZE QkIwN0NDNEYwREFEMDZFQTBBRkU0MUIwN0ExQUVBRUZCNDQ2NEUSHG1nb3JueUBn ZW50b28ub3JnAAoJELB6GurvtEZOvgUP/iP9Gtbwu7xNs/s59G33tz+Gmd12zk5s 8h3qQgOITRcqQNwCqFwOAb6uChYUj7e0s2MKsxbwXXt8tpH7JnMYKoXD3BigFZVL GOT79zH3B0qgroJuP0uolr1wccke5koczg03g3xQ0qAZwz8FUrqOrzW2AGdNdyhI 3RAtyARvJTiLm9pUtJHLWYsG4jn/oaO5QjhOUbGgqQOPI1Vfv4pqpBxdHGcqDjTl 7ZrKO5lk3JEjDGm2p2dGlxffMTYnBZFv/EPQvyD/XMYrY73ayy4gmZ8roSVvo2wu kOdoOV7gTl96g9MGaA4PaO6WINWWCdyB2sBpD9Y5Q/s4nyuem4srkDPwOanfSfTj n+7rHHo1J5X6aJXvyMLwFeHTrIS/HV5Ws8dhBpYwHRzU+uryEU6RL9WI/uWMGcRW rPpoTqj3BPiUvdEc24CAeP2MJoYXNKdjlr5TWaLV+TZAV+fgXH2cbFA6f0fsAtL9 iKRgO/m+bITdoliGXkAcXVj+Ej3RIMQxylV9OOS6TPmsV5EZKMIe/yJzC31DITbe T5ASRUjCgJspvX9thmwyZZ8QB6yIEwH15MLYP/goeeAFLpo5aHbl2zQDyILlYlfR 1RIj30XOeHNNZwhfo0f/Y1kRNjIFXKBt0vBEUZsGktnvFFrZynKFOGA/+GitAgeC thG1Z6M1FqQm =FjHz -----END PGP SIGNATURE----- --=-Tq4OlBpya5VXQpdBn4hy--