| 1 |
On Thu, 15 Jun 2017 18:37:16 +0200 |
| 2 |
Alexis Ballier <aballier@g.o> wrote: |
| 3 |
> > So you're saying that at the end of this, there's an ENFORCED_USE |
| 4 |
> > solver that spits out some answer that may or may not be in any way |
| 5 |
> > a sane solution to the conflict. |
| 6 |
> > |
| 7 |
> > I don't see how that's helpful to a user. |
| 8 |
> |
| 9 |
> Define sane. |
| 10 |
> The definition of the solver is made to change the least possible of |
| 11 |
> the inputs and is completely and easily predictable by the person |
| 12 |
> writing the constraint. That is something I would call sane. |
| 13 |
|
| 14 |
The problem is not just writing a resolver that spits out a valid |
| 15 |
output. The problem is writing a resolver which will never go and |
| 16 |
uninstall bash as a result of unintended combinations of inputs (which |
| 17 |
Portage used to do, but there's now a special exception for system |
| 18 |
packages, so it will only occasionally unexpectedly uninstall critical |
| 19 |
packages that aren't explicitly in system due to virtuals instead). |
| 20 |
This is *hard*. |
| 21 |
|
| 22 |
A bad suggestion to the user is worse than no suggestion at all. Unless |
| 23 |
you can safely determine that there aren't any unintended consequences |
| 24 |
of your rule, the focus needs to be on producing good error messages |
| 25 |
so the user can figure the problem out, not on producing bad solutions |
| 26 |
that will confuse things even more. |
| 27 |
|
| 28 |
-- |
| 29 |
Ciaran McCreesh |
Archives