On Thu, 15 Jun 2017 17:45:09 +0100 Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> On Thu, 15 Jun 2017 18:37:16 +0200 > Alexis Ballier <aball...@gentoo.org> 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.
