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 A7968139694 for ; Sun, 11 Jun 2017 16:18:21 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3DB0521C1F8; Sun, 11 Jun 2017 16:18:16 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 D30BC21C08C for ; Sun, 11 Jun 2017 16:18:15 +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 790AD341819 for ; Sun, 11 Jun 2017 16:18:14 +0000 (UTC) Date: Sun, 11 Jun 2017 18:18:09 +0200 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] Restricting allowed nesting of REQUIRED_USE Message-ID: <20170611181809.1c0b98f1@gentoo.org> In-Reply-To: <1497047407.15114.2.camel@gentoo.org> References: <1497047407.15114.2.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: 5f8edadc-2d60-472d-90d1-1fe6728db8db X-Archives-Hash: 47ea9ab74851e30117f3577de8be7214 On Sat, 10 Jun 2017 00:30:07 +0200 Micha=C5=82 G=C3=B3rny wrote: > Hi, everyone. >=20 > As you may or may not know, PMS says rather little about REQUIRED_USE > [1,2]. The largest past of the definition is shared with other > dependency-like specifications [3]. >=20 > Similarly to regular dependency specifications, PMS is rather lax in > nesting things. While this isn't a major problem for dependencies > where the syntax is limited to any-of, all-of and USE-conditional > groups (though it already may cause some confusion there), it allows > quite a bit of a mayhem with the full set of REQUIRED_USE clauses. >=20 > We have five different kinds of clauses there: any-of, at-most-one-of, > exactly-one-of, all-of and USE-conditional. Furthermore, unlike > in dependency specifications, the last type is circular with flags > enforced by REQUIRED_USE constraints. >=20 > While nesting all of those clauses is technically valid (and can be > logically verified), it has no proven usability. As a result, it is > either not used at all or has a few use cases which suffer from poor > readability and can be easily replaced with *much simpler* > constraints. In fact, allowing them is not solving any issues but > only introducing more when developers fail at using them. >=20 > I would therefore like to discuss restricting nesting of REQUIRED_USE > clauses. >=20 >=20 > What's my take in this? As you have probably noticed (and stopped > reading) I am working with Alexis on solving REQUIRED_USE constraints > automatically. We're working towards a few goals: keeping things > simple, giving predictable solutions, and being able to automatically > validate whether the constraints are solvable. >=20 > While we're near solving almost everything, the complex clauses add > unnecessary complexity (both to the spec and to the code) which does > not really benefit anyone, and bring solutions that can not be > predictable because the clauses are ambiguous by design. >=20 > To avoid adding this complexity, it would be reasonable to ban at > least some of the non-useful combinations. This means either banning > them completely (in a future EAPI + possibly repoman) so that > developers do not even try to use them, or disabling autosolving when > they are being used). I'm not sure it is worth restricting too much in the spec, at least now. It certainly has benefits, but the extra complexity they add forces to thoroughly think about how to design the proper solver, which I don't see as a bad thing. The main problem is that the solver, in those complex cases, will provide results that, at least to me, do not seem natural. It'd probably be a very good thing to restrict the allowed nesting since they add (runtime) complexity to the solver & checker, like a repoman warning and/or error, depending on some threshold. On the other hand, the syntax you propose seems way much saner. I like it and consider it is a good way to guide developers into writing easily predictable constraints. However, I would not disable auto solving when this does not match, I would have a generic algorithm, and wait for field testing before deciding if people are happy with the results or if they prefer to rewrite their constraints in a saner way to have a straightforward interpretation of the solver results. Bests, Alexis.