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 BCAEF139694 for ; Thu, 15 Jun 2017 17:39:01 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 93176224068; Thu, 15 Jun 2017 17:38: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 3DB1F224019 for ; Thu, 15 Jun 2017 17:38:55 +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 ACE92341822; Thu, 15 Jun 2017 17:38:53 +0000 (UTC) Message-ID: <1497548328.31152.7.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: Thu, 15 Jun 2017 19:38:48 +0200 In-Reply-To: <20170615180700.11b3ef6a@gentoo.org> References: <1496071993.31087.1.camel@gentoo.org> <1496671825.1230.3.camel@gentoo.org> <20170605192433.6238797b@gentoo.org> <1496686212.1222.4.camel@gentoo.org> <20170606140803.051f8048@gentoo.org> <1496770744.1157.1.camel@gentoo.org> <20170607101759.7e21f0f6@gentoo.org> <1496827679.2129.3.camel@gentoo.org> <20170607115654.2a5da5e2@gentoo.org> <1496999960.29391.1.camel@gentoo.org> <20170609134110.418ae6ac@gentoo.org> <1497012847.25475.4.camel@gentoo.org> <20170609161619.1b72ad5b@gentoo.org> <1497025310.25475.7.camel@gentoo.org> <20170611180518.5e28ddfa@gentoo.org> <20170612110836.7b670c93@gentoo.org> <1497295036.1575.10.camel@gentoo.org> <20170613122745.455b39f7@gentoo.org> <1497392022.29918.1.camel@gentoo.org> <20170614110659.6bf4d1c2@gentoo.org> <1497443088.1223.1.camel@gentoo.org> <20170614151606.70d5d559@gentoo.org> <1497448658.1223.3.camel@gentoo.org> <20170614160939.1b15d2fa@gentoo.org> <1497542353.2933.1.camel@gentoo.org> <20170615180700.11b3ef6a@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-rtMI/t/P/e3bDfOjf0eZ" 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: fd84bbc2-e299-446e-88e2-5ab839bbfad9 X-Archives-Hash: 965de9197d981878e2da0d6b5c95b379 --=-rtMI/t/P/e3bDfOjf0eZ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On czw, 2017-06-15 at 18:07 +0200, Alexis Ballier wrote: > On Thu, 15 Jun 2017 17:59:13 +0200 > Micha=C5=82 G=C3=B3rny wrote: >=20 > > On =C5=9Bro, 2017-06-14 at 16:09 +0200, Alexis Ballier wrote: > > > On Wed, 14 Jun 2017 15:57:38 +0200 > > > Micha=C5=82 G=C3=B3rny wrote: > > > [...] =20 > > > > > [...] =20 > > > > > > > > > > [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:ReqUs= e =20 > > > > > > > > >=20 > > > > > > > > > I really don't like the reordering thing. Even the > > > > > > > > > restricted syntax does not fix the issue with '^^ ( a b > > > > > > > > > ) b? ( a )' already mentioned here. It'd be much better > > > > > > > > > and simpler for the spec just to assign a fixed value > > > > > > > > > and use the solving rules with those. =20 > > > > > > > >=20 > > > > > > > > You're not going to convince me by providing examples > > > > > > > > that are utterly broken by design and > > > > > > > > meaningless ;-). =20 > > > > > > >=20 > > > > > > > Well... if it's so obvious that the example is broken by > > > > > > > design that you don't even bother to explain why, I assume > > > > > > > you have an algorithm for that. Where is the code ? What > > > > > > > are the numbers ? How many ebuilds might fail after > > > > > > > reordering ? How can this be improved ? =20 > > > > > >=20 > > > > > > Are you arguing for the sake of arguing here? I just presumed > > > > > > that this example is so obviously broken there is no point > > > > > > wasting any more time on it. The code of nsolve clearly > > > > > > detects that, so I don't really understand what you're trying > > > > > > to prove here. =20 > > > > >=20 > > > > > Those are real questions. You should take breath, think a bit > > > > > about it, and try to run the 2 possible orderings of the ^^ > > > > > through nsolve or even solve.py. They both are very happy (and > > > > > are right to be) with the above ordering. You might want to > > > > > think a bit more about what is the relation between this broken > > > > > 10 chars example and the 10 lines python targets one below. > > > > >=20 > > > > > You should also realize that all the above questions have > > > > > already been answered in length if you do as I suggest. =20 > > > >=20 > > > > No. I have already spent too much time on this. We're already long > > > > past all useful use cases, and now I feel like you're going to > > > > argue to death just to find a perfect algorithm that supports > > > > every absurd construct anyone can even write, if only to figure > > > > out the construct is completely useless. =20 > > >=20 > > > I'm not going to argue to death. It's already proven reordering is > > > broken. > > > =20 > > > > If you want to play with it more, then please by all means do > > > > so. =20 > > >=20 > > > There is nothing to do for reordering. It's broken by design. > > > =20 > > > > However, do not expect me to waste any more of my time on it. I've > > > > done my part, the code works for all reasonable use cases and > > > > solves all the problems I needed solving. If you want more, then > > > > it's your job to do it and solve the resulting issues. =20 > > >=20 > > > Like... writing code handling all the cases and describing how it > > > works ? We're past that. The only thing we're not past is that you > > > fail to understand it and attempt to block it. > > > =20 > >=20 > > Then please provide a single valid example that: >=20 > app-text/wklej-0.2.1-r1 ^^ ( python_single_target_pypy > python_single_target_pypy3 python_single_target_python2_7 > python_single_target_python3_4 python_single_target_python3_5 > python_single_target_python3_6 ) python_single_target_pypy? > ( python_targets_pypy ) python_single_target_pypy3? > ( python_targets_pypy3 ) python_single_target_python2_7? > ( python_targets_python2_7 ) python_single_target_python3_4? > ( python_targets_python3_4 ) python_single_target_python3_5? > ( python_targets_python3_5 ) python_single_target_python3_6? > ( python_targets_python3_6 ) vim? ( ^^ ( python_single_target_python2_7 > ) ) >=20 >=20 > Simplified as: > ^^ ( a b ) c? ( b ) >=20 > (see the pattern now ? :) ) >=20 > > a. is completely 'correct' (that is, provides a valid, predictable > > and acceptable solution) with the default ordering O_a, >=20 > c? ( b ) ^^ ( b a ) >=20 >=20 > > b. is not 'correct' with at least one reordering O_b (assuming only > > > > , ^^, ?? is subject to reordering), >=20 > c? ( b ) ^^ ( a b ) >=20 > >=20 > > c. nsolve reports O_a as all good, and O_b as not good. >=20 > I'll let you run this. It does. >=20 > > The best way to convince me is through valid examples. >=20 >=20 > It is also easier to be convinced when you try to understand and ask > for clarifications instead of just rejecting without thinking :) >=20 Ok, now I get your point. Not that I like it but I don't see any sane way around it. The question then is, how can you reliably ensure that developers will use the same ordering in cross-relevant packages? For example, consider the following: ^^ ( provider_ssl_openssl provider_ssl_libressl ) Since those providers block each other, all packages will have to have either openssl or libressl consistently (or another provider). The reordering idea was mostly addressing this. However, it just occurred to me it only solved some the case when user selected both and not the one where neither was preferred over the other. Without reordering, I think we need to enforce the specific ordering consistently across the tree. Any idea how to achieve that? --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-rtMI/t/P/e3bDfOjf0eZ 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+0Rk4FAllCxilfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZE QkIwN0NDNEYwREFEMDZFQTBBRkU0MUIwN0ExQUVBRUZCNDQ2NEUSHG1nb3JueUBn ZW50b28ub3JnAAoJELB6GurvtEZOUQAP/j6zbYo4txJOmgs8eO63sh/KvZQPHPnE D+T1z5r0243Mi3uAx6bMe05RoYJY14fQ9g+qYETj+v0mERkXSV5q40rk4S/8EATT yJ6nIgHjdNoMCcBsuKPW2UeZkeRIEbDNT+HQ8M8+s5rgzjSw4dHJoy9nTkuRGW90 DfdgghiOXww+BFUNhi2uQc3LVHiUQHHZkkG9zfuIPVonHbOKd3DRDksJO6u2j/t1 lPA/fGlSYuzVEH1dnwiAl3Lv5pwydNFJcbebtvABIy7e351dPvPQR39l1j9/f4yP 4H/dd6z2qCbdT6I3HfHyTOyMSKqdY8ccv0LD5m4LtGCxm6lxClVu18kQRiQLazYI Q+0xmy+qe3l5yukA+azc4kA9gHpzlEV1tEAZ1nhy5HP2B92248zjNgZzudU3VXyN xlY4i9h+bvhc+8bUsHOJ1lGS1OjCHeZMU265b3t0tp3giIER4D58+wdfi2pe2eK1 IApXqOMSgzPSL+eyO26QGLGXenYqsUWBvVjNnvoe7tK6OBBpxIi7FEitCfBCX48U PXI0Bkto33qv/9pzqHZDyP0y1sDekWkelxg5W3H1QtT8L6OP2UJm8LlwXtB4naqj lIhK3/giy+YkYeOOFi0zBL9wcScSGiEa/vBJqqctqRf9fLmktvQgvzkSv3mgw8rv 7RgSX1J8inB3 =g6zK -----END PGP SIGNATURE----- --=-rtMI/t/P/e3bDfOjf0eZ--