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 A22F9139694 for ; Tue, 30 May 2017 09:34:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3E64021C073; Tue, 30 May 2017 09:34:46 +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 DD76021C012 for ; Tue, 30 May 2017 09:34:45 +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 5B2D53416C2 for ; Tue, 30 May 2017 09:34:44 +0000 (UTC) Date: Tue, 30 May 2017 11:34:39 +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: <20170530113439.06178b52@gentoo.org> In-Reply-To: <1496132988.1617.3.camel@gentoo.org> References: <1496071993.31087.1.camel@gentoo.org> <20170529200037.2559f80a@gentoo.org> <1496093035.12795.3.camel@gentoo.org> <20170530094245.40e1cf64@gentoo.org> <1496132988.1617.3.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: ee1be56c-4632-4cdc-8579-abadbfa04776 X-Archives-Hash: e550eb40ca72fbd358d8c5edb2ad561d On Tue, 30 May 2017 10:29:48 +0200 Micha=C5=82 G=C3=B3rny wrote: > 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. Nobody's blaming you for that, rather the contrary :) > > > 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 > >=20 > > If the point is to automatically propose a solution, then who cares > > about readability? Users won't even see that message. =20 >=20 > But users should be able to reasonably figure out what happened, > exactly. There's a difference in quality between the two messages: >=20 > a. 'foo is enabled; bar, got disabled', >=20 > b. 'one of foo, bar, baz had to be enabled =3D> you chose foo'. >=20 > Not saying you can't figure it out. Saying in a more complex case, > grouping constraints like this is helpful. Why not then. You're right it makes more sense. > > 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. =20 >=20 > 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. I've re-read your proposal entirely and I don't see where you describe how to establish priorities. You describe how users can specify those, but nowhere do I see any default priority being mandated. If you describe and mandate it, then all is good I think. As I said, there are plenty of ways to solve the problem but it has to be mandated otherwise you're just postponing issues, not solving them. Alexis.