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 0FF30139694 for ; Fri, 2 Jun 2017 13:50:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D33F421C06B; Fri, 2 Jun 2017 13:49:58 +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 7661C21C03E for ; Fri, 2 Jun 2017 13:49:58 +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 506FA3416BF; Fri, 2 Jun 2017 13:49:56 +0000 (UTC) Message-ID: <1496411391.29233.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: Fri, 02 Jun 2017 15:49:51 +0200 In-Reply-To: <20170602131806.6efc7b0e@gentoo.org> References: <1496071993.31087.1.camel@gentoo.org> <20170529200037.2559f80a@gentoo.org> <1496093035.12795.3.camel@gentoo.org> <20170530094245.40e1cf64@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> <1496385450.1439.1.camel@gentoo.org> <20170602131806.6efc7b0e@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-Ao2CZEj+TCnfMsHjHcJ+" 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: dbb49296-6ea2-4bd0-812d-3efe2b89fdbb X-Archives-Hash: 5c8048874bdf1b1cbac7054911bbdc25 --=-Ao2CZEj+TCnfMsHjHcJ+ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On pi=C4=85, 2017-06-02 at 13:18 +0200, Alexis Ballier wrote: > On Fri, 02 Jun 2017 08:37:30 +0200 > Micha=C5=82 G=C3=B3rny wrote: >=20 > > On czw, 2017-06-01 at 23:31 +0200, Micha=C5=82 G=C3=B3rny wrote: > > > On czw, 2017-06-01 at 10:55 +0200, Alexis Ballier wrote: =20 > > > > On Wed, 31 May 2017 21:02:24 +0200 > > > > Micha=C5=82 G=C3=B3rny wrote: > > > > =20 > > > > > On =C5=9Bro, 2017-05-31 at 19:39 +0200, Alexis Ballier wrote: = =20 > > > > > > > > Again, you *need* to process the constraints in order. > > > > > > > > '!a? ( b ) !b? ( a )' is not deterministic when none of a > > > > > > > > and b are enabled otherwise. =20 > > > > > > >=20 > > > > > > > You can't rely on any particular order of constraints, > > > > > > > especially when eclass stacking comes into play. You could > > > > > > > try defining some constraint- sorting algorithm but it's > > > > > > > going to be complex and it's usefulness will be limited > > > > > > > anyway due to various kinds of grouping. =20 > > > > > >=20 > > > > > >=20 > > > > > > Better have some order: If half of the above constraint comes > > > > > > from ebuild and the other half comes from eclass, then PM > > > > > > might toggle 'a' or 'b' depending on the phase of the moon > > > > > > which is specifically what we're trying to avoid. =20 > > > > >=20 > > > > > No, it can't. That's the whole point. The algorithm must be > > > > > defined so that it is always predictable independently of order > > > > > (maybe except the ordering inside ^^, ||, ??) and independently > > > > > of how it's nested (i.e. 'a? ( b? ( c ) )' must give the same > > > > > result as 'b? ( a? ( c ) )'). =20 > > > >=20 > > > > This is a lot of handwaving without real description of how it > > > > would work. This starts to look a lot like confluence in > > > > rewriting systems and you want developers to write only confluent > > > > rules and repoman to decide that. Good luck with that. =20 > > >=20 > > > I'm sorry, what I said was quite stupid. I did some thinking and > > > testing today, and the algorithm can be actually quite trivial. The > > > real issue is getting a correct input, that is REQUIRED_USE > > > constraints that have only one solution. >=20 > Don't be sorry, it's not stupid actually. There are various ways to > determinize how the constraints should be solved. Once that is defined, > one just needs to apply the rules to the constraints to get a > temptative solution, making the algorithm trivial, indeed. Depending on > how you do actually determinize the whole thing can make ensuring > uniqueness (or even the existence) of a solution quite a pain. That's > where the trade-offs between ebuild writers wishes and solving the issue > come into play. I see this long thread as a quite interesting > discussion where we're trying to converge towards something that leaves > the problem easily solvable without asking too much to ebuild writers. >=20 > [...] > > > The biggest issue for me right now is to find a way to determine > > > whether a particular REQUIRED_USE constraint can have only one > > > solution, independently of the order of non-n-ary constraints. > > > However, some of it can be easily eyeball-checked using a graph. > > > =20 > >=20 > > Well, I've looked at it more and you were right. While keeping them > > order-independent is a noble goal, it's not really feasible, > > especially if we assume that n-ary constraints can be reordered. So I > > think we can assume left-to-right ordering now (with multiple passes, > > if necessary). >=20 >=20 > There are ways to guarantee order-independence, your gtk+ answer in the > previous email suggests one: At most one constraint solving rule can be > applied in any situation; that's what you did by putting the || > under !xinerama. This is a quite extreme way to ensure confluence but > that works. I've not thought too much about it but I think we'd lose > too much in expressivity though. For the xinerama rule, you may prefer the opposite rule, i.e.: !X? ( !xinerama ) If you did so, I can't think of a way to express it correctly while preserving full allowance of reshifting ||. So yes, we'd lose too much. One thing we lose is the ability to clearly check whether the constraint 'makes sense'. Previously, we could (at least theoretically) check whether it has a single solution and complain otherwise. With left-to- right, I don't see any way to tell the developer 'something stupid is going to happen now, you probably meant something else'. But I guess that's still an improvement over what we have now. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-Ao2CZEj+TCnfMsHjHcJ+ 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+0Rk4FAlkxbQBfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZE QkIwN0NDNEYwREFEMDZFQTBBRkU0MUIwN0ExQUVBRUZCNDQ2NEUSHG1nb3JueUBn ZW50b28ub3JnAAoJELB6GurvtEZOijwP/2WmIbA0NJucLr2Z7/L3ph0CMHz6F4xJ t/nMDdpH8G70Ev8yjkQUua8wV+stNdcZZHHMGC7F2uBRzGXyWbfJGoyvzHNgbT5n ENf9LEQ4J9FgO3y+4KDt2h9I9pDsKlE3cKwtxE7/7fXvtGjnsKY3ztGHrIbUzssg 6vROjCz5Cj5DxSjKR4ESke1wB7HDOKyTmy8aA1MG9cFIgtcw2cZSvBzq9grvHNaa N42ysybufa9slk1F54tHFRMf8Iu4YIoa5HchDY4ZQ0R/xZF63t4VwAW4ySRbbzJE y8QuY+3pgPe8FvdfdH7mzN0UWY+S5ONRGoXs2UWuswwS0Owx2HLN/lIVIOeAsTj/ lB5hZ9puCvZuokuWRGWdlI/lCTHGLb1UNazPgMu6556qJKprkQXZHEevecvTR86B GQKeFvoBcEDgzgLWp3RVvLbgELz6ryFEt3Kfmw9cr3kjPXAfgjEpwTUArQ27l22p z2jWvdqH18rXfFw1Ljpakc+Ir/0NY30QlvFJKK86Xxp3fxiGJ5V4gys9CPmncJ0N ovpI1b5soFEX3UX0BIbV6hbB9/izFULSImYZtMlExQek6/T7Azz+IsPQYWBAliqF FByT/vykCTzVEMLSmLP6SMbkHlKx4OzVk2aVRJ0Edy3p9wMwzNipupI5nkQSoMWz 7iphwigMs0AT =COX3 -----END PGP SIGNATURE----- --=-Ao2CZEj+TCnfMsHjHcJ+--