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 9A199139694 for ; Wed, 14 Jun 2017 14:09:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5A7A921C092; Wed, 14 Jun 2017 14:09:47 +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 F327D21C054 for ; Wed, 14 Jun 2017 14:09:46 +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 73D67341908 for ; Wed, 14 Jun 2017 14:09:45 +0000 (UTC) Date: Wed, 14 Jun 2017 16:09: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: <20170614160939.1b15d2fa@gentoo.org> In-Reply-To: <1497448658.1223.3.camel@gentoo.org> References: <1496071993.31087.1.camel@gentoo.org> <20170604105938.2b40157f@gentoo.org> <20170605095516.0b463432@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> 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: 25ed0b2f-9a46-41d5-9bd9-205a2f6b9d4c X-Archives-Hash: a145d7a44b72311cef1f8ca77c4e9591 On Wed, 14 Jun 2017 15:57:38 +0200 Micha=C5=82 G=C3=B3rny wrote: [...] > > [...] =20 > > > > > > > [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:ReqUse = =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. I'm not going to argue to death. It's already proven reordering is broken. > If you want to play with it more, then please by all means do so. There is nothing to do for reordering. It's broken by design. > 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. 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. Alexis.