1 |
On Wed, 12 Aug 2015 17:08:59 +0200 |
2 |
Ulrich Mueller <ulm@g.o> wrote: |
3 |
|
4 |
> >>>>> On Wed, 12 Aug 2015, Alexis Ballier wrote: |
5 |
> |
6 |
> > i.e. something that really tells the PM how to automate the choice: |
7 |
> > - 'qt5 -> !qt4' is rather straightforward to solve and tells the PM |
8 |
> > how (note that it is not equivalent to 'qt4 -> !qt5') |
9 |
> > - '^^ ( qt5 qt4 )' requires the PM to make a choice in order to |
10 |
> > automate it |
11 |
> |
12 |
> I was thinking about some syntax like this: |
13 |
> |
14 |
> REQUIRED_USE="|| ( +foo bar ) ^^ ( +qt5 -qt4 )" |
15 |
> |
16 |
> The package manager would first evaluate each group in REQUIRED_USE |
17 |
> with the original set of USE flags. If that doesn't evaluate to true, |
18 |
> retry with flags changed as indicated by the + and - signs. |
19 |
|
20 |
|
21 |
it is more in the line of what we currently do, but that doesn't |
22 |
resolve the 'sat' problem: it doesnt make clear we don't want to |
23 |
satisfy it but rather walk through a list of causes and consequences |
24 |
|
25 |
now that i'm thinking more about it, killing || and ^^ would probably |
26 |
solve the automation problem: |
27 |
qt? ( !qt4? ( qt5 ) qt4? ( !qt5 ) ) vs 'qt? ( ^^ ( qt4 qt5 ) )' |
28 |
|
29 |
a bit longer but PM now knows what to do |
30 |
|
31 |
|
32 |
both are equally expressive: |
33 |
|
34 |
|| ( a b ) <-> !a? ( b ) |
35 |
(or !b? ( a ) depending on preference) |
36 |
Here PM will enable b if a is disabled (a if b is disabled in the |
37 |
latter form) |
38 |
|
39 |
^^ ( a b ) <-> !a? ( b ) a? ( !b ) |
40 |
Here PM will enable b if a is disabled; disable b if a is enabled |
41 |
|
42 |
|
43 |
No need for a new syntax :) |
44 |
|
45 |
Alexis. |