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 0544C139694 for ; Thu, 15 Jun 2017 16:37:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5F316E0DC2; Thu, 15 Jun 2017 16:37:24 +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 07AF1E0DAC for ; Thu, 15 Jun 2017 16:37:23 +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 94A03341698 for ; Thu, 15 Jun 2017 16:37:22 +0000 (UTC) Date: Thu, 15 Jun 2017 18:37:16 +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: <20170615183716.0d92a5d2@gentoo.org> In-Reply-To: <20170615173240.70e89fef@snowblower> References: <1496071993.31087.1.camel@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> <20170615171357.5a190869@snowblower> <20170615181904.25479e47@gentoo.org> <20170615172226.533e1ac9@snowblower> <20170615183010.6a249ee3@gentoo.org> <20170615173240.70e89fef@snowblower> 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=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 408c0f04-f2d1-4c17-9214-728973ac5328 X-Archives-Hash: 1c13a4e51a9ddc3bdec734ac72d2c7ea On Thu, 15 Jun 2017 17:32:40 +0100 Ciaran McCreesh wrote: > On Thu, 15 Jun 2017 18:30:10 +0200 > Alexis Ballier wrote: > > On Thu, 15 Jun 2017 17:22:26 +0100 > > Ciaran McCreesh wrote: > > > On Thu, 15 Jun 2017 18:19:04 +0200 > > > Alexis Ballier wrote: > > > > On Thu, 15 Jun 2017 17:13:57 +0100 > > > > Ciaran McCreesh wrote: > > > > > On Thu, 15 Jun 2017 18:07:00 +0200 > > > > > Alexis Ballier wrote: > > > > > > > The best way to convince me is through valid > > > > > > > examples. > > > > > > > > > > > > It is also easier to be convinced when you try to understand > > > > > > and ask for clarifications instead of just rejecting without > > > > > > thinking :) > > > > > > > > > > The problem with this entire proposal is that it's still in > > > > > "well I can't think of how it could possibly go wrong" > > > > > territory. We need a formal proof that it's sound. History has > > > > > shown that if something can be abused by Gentoo developers, it > > > > > will be abused... > > > > > > > > Had you read the thread you would have noticed that I provided > > > > an algorithm giving sufficient conditions for the solver to > > > > work. That is, if developers pay attention to repoman > > > > warnings/errors, it will never fail. Obviously, since we're > > > > still in the SAT space, you can ignore the errors and make it > > > > fail, but it'll never be worse than what we currently > > > > have. > > > > > > You have shown that you produce a solution, not the solution > > > that's actually wanted. > > > > Since 'wanted' is still undefined, I'd say it produces the defined > > solution and you can adapt to the definition to get what you want. > > So you're saying that at the end of this, there's an ENFORCED_USE > solver that spits out some answer that may or may not be in any way a > sane solution to the conflict. > > I don't see how that's helpful to a user. > Define sane. The definition of the solver is made to change the least possible of the inputs and is completely and easily predictable by the person writing the constraint. That is something I would call sane.