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 3C635139694 for ; Thu, 15 Jun 2017 16:55:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5561621C1ED; Thu, 15 Jun 2017 16:55:53 +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 054F121C0E1 for ; Thu, 15 Jun 2017 16:55:52 +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 25CDC340806 for ; Thu, 15 Jun 2017 16:55:50 +0000 (UTC) Date: Thu, 15 Jun 2017 18:55:45 +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: <20170615185545.356d4492@gentoo.org> In-Reply-To: <20170615174509.0260522b@snowblower> References: <1496071993.31087.1.camel@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> <20170615183716.0d92a5d2@gentoo.org> <20170615174509.0260522b@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: 3975e1a2-cce1-4674-871e-79f02b9c518a X-Archives-Hash: 0d1779b7974abf9f6cf4ab464ef1ebf7 On Thu, 15 Jun 2017 17:45:09 +0100 Ciaran McCreesh wrote: > On Thu, 15 Jun 2017 18:37:16 +0200 > Alexis Ballier wrote: > > > 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. > > The problem is not just writing a resolver that spits out a valid > output. The problem is writing a resolver which will never go and > uninstall bash as a result of unintended combinations of inputs (which > Portage used to do, but there's now a special exception for system > packages, so it will only occasionally unexpectedly uninstall critical > packages that aren't explicitly in system due to virtuals instead). > This is *hard*. We're not talking about solving deps here. > A bad suggestion to the user is worse than no suggestion at all. > Unless you can safely determine that there aren't any unintended > consequences of your rule, the focus needs to be on producing good > error messages so the user can figure the problem out, not on > producing bad solutions that will confuse things even more. The guarantee comes from the fact that the output is always in the space of all possible inputs from the user. So, if some output will kill a kitten, so does some input. Of course, implementation can decide to error out and propose a solution, to continue but print big fat warnings, etc. I like the initial proposal in that regard. Alexis.