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 61E5B139694 for ; Fri, 2 Jun 2017 06:37:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id AD771E0D76; Fri, 2 Jun 2017 06:37:36 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.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 4D3ADE0BCF for ; Fri, 2 Jun 2017 06:37:36 +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 4FEB6341743; Fri, 2 Jun 2017 06:37:34 +0000 (UTC) Message-ID: <1496385450.1439.1.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 08:37:30 +0200 In-Reply-To: <1496352685.30502.4.camel@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> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-4U3YkL5vIOmPKYP9ROiz" 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: f78fc9b3-2e01-4898-bd5f-929c8b3306ad X-Archives-Hash: dc66f8c00bdc1d92c86cac55f66176a9 --=-4U3YkL5vIOmPKYP9ROiz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: > > 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: > > > > > > 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 s= o > > > 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 > > 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 > 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 > That is the whole problem I was signaling, and which I seem to have lost > sight of: solving is trivial, ensuring that the constraint can have only > one solution isn't. Hopefully, most of the simple constraints in use > will 'just work'. >=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 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 Best regards, Micha=C5=82 G=C3=B3rny --=-4U3YkL5vIOmPKYP9ROiz 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+0Rk4FAlkxB6pfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZE QkIwN0NDNEYwREFEMDZFQTBBRkU0MUIwN0ExQUVBRUZCNDQ2NEUSHG1nb3JueUBn ZW50b28ub3JnAAoJELB6GurvtEZO9Q8P/0f9my8K1fryrLyPONC2KGyxzkgBSnpb a1jOwc9QbFyphR6dmmRqddXdEDpJgBBdBjZXym1ZLjQQ8XVG9JSJZGO0zFsB72lB +hN2tVpPueOygIRcCYmyEHvkAbkY8PoExyMg0Yky1zzJoPc+ksnZ+kkesL2puG8j HX9moSUYhPbrF5+tBIxixCVxW/G4Qet57qCivHUsLPh6Smfo1NtjcK2WwLoCjL4n uqTBSMDZs8oJegYJ/MeQLpyoJ6YpqPwqIlujVmzRTLpOOc7b44strXkglZU+8m6e F/s4zc7xCicHZLArjYf7RPo8c8PXfk8EmvKq7p7JJ51u8gs3Jm8mggNr/QJg9jQG CmNe2xp1P7so/K1mSY4ThO0F2lCLJWb/sV5su8TE6A1sG3L3kCICvM6XJ0B7yzOL 5qf7J/hGVcCDhYKizrpvoqo0F/XP11H9rFtwLKo6XcOXF4hGG+nqNJmnB8To8/yG 3ZUgtoZRIJXdYBMwNLHRuD8c3a89JmdLm3Z8kPsYWgC9NDLL1nhsMEVmx1f36uVW gJjpZJA3fYoMWDtkFfHhsslLQzEuregJAk8VjLpwB1gtTdqAzaqZHNYtgID+hwW1 FDMzvW5KFGOVS8raxoxvqMavh7rDkbBJAMlXgEwc0bleSs0/4l85UzU8Z76OnSBI 38vrV09Jm74d =VRE6 -----END PGP SIGNATURE----- --=-4U3YkL5vIOmPKYP9ROiz--