1 |
On śro, 2017-05-31 at 19:39 +0200, Alexis Ballier wrote: |
2 |
> > > Again, you *need* to process the constraints in order. '!a? |
3 |
> > > ( b ) !b? ( a )' is not deterministic when none of a and b are |
4 |
> > > enabled otherwise. |
5 |
> > |
6 |
> > You can't rely on any particular order of constraints, especially when |
7 |
> > eclass stacking comes into play. You could try defining some |
8 |
> > constraint- sorting algorithm but it's going to be complex and it's |
9 |
> > usefulness will be limited anyway due to various kinds of grouping. |
10 |
> |
11 |
> |
12 |
> Better have some order: If half of the above constraint comes from |
13 |
> ebuild and the other half comes from eclass, then PM might toggle 'a' or |
14 |
> 'b' depending on the phase of the moon which is specifically what we're |
15 |
> trying to avoid. |
16 |
|
17 |
No, it can't. That's the whole point. The algorithm must be defined so |
18 |
that it is always predictable independently of order (maybe except |
19 |
the ordering inside ^^, ||, ??) and independently of how it's nested |
20 |
(i.e. 'a? ( b? ( c ) )' must give the same result as 'b? ( a? ( c ) )'). |
21 |
|
22 |
If you start relying on stuff like ordering, you're one step from making |
23 |
stuff suddenly fail or change meaning due to minor changes, like sorting |
24 |
stuff. |
25 |
|
26 |
> eclass stacking is not a problem: specify if it's append or prepend and |
27 |
> be done. |
28 |
|
29 |
What about multiple inherits with guards? Next thing I know, we end up |
30 |
putting REQUIRED_USE outside guards (like we have to do with |
31 |
EXPORT_FUNCTIONS now) because you need a specific order, and guards make |
32 |
it unpredictable. |
33 |
|
34 |
> Note that if you want to remove the need for an order, you'll need to |
35 |
> ensure that all orderings of the constraints give the same result. It's |
36 |
> not sufficient to "only" check all possible inputs. |
37 |
|
38 |
That's the matter of the algorithm. |
39 |
|
40 |
> Also, what happens if we applied all the constraints and obtained some |
41 |
> useflags setting that still fails REQUIRED_USE check ? |
42 |
|
43 |
It can't happen. If you can apply all the constraints, then implicitly |
44 |
REQUIRED_USE is satisfied. If you can't apply all the constraints, then |
45 |
it just fails. Of course, we want to ultimately avoid that case. |
46 |
|
47 |
> > The point would be: by definition, the solver should be able to touch |
48 |
> > *any* USE flag. If it can't, it mostly implies that you can't use |
49 |
> > the automatic solver, and so the case is irrelevant for checking. |
50 |
> > Attempting to go beyond that is going to give a lot of complexity |
51 |
> > and most likely kill the whole idea. |
52 |
> > |
53 |
> > One thing we need to worry about are masks. We need to think about |
54 |
> > them. |
55 |
> |
56 |
> It makes zero difference for any solver if you replace variables |
57 |
> (useflags) by 'true' or 'false' constants (masked/forced/user-forced |
58 |
> useflags). It's even simpler actually. Whether the formula is not |
59 |
> constantly 'true' (ie REQUIRED_USE is useless) or constantly |
60 |
> 'false' (ie there's no way to solve it) is equivalent to solving SAT. |
61 |
> We likely don't want that for repoman running on php. |
62 |
> |
63 |
|
64 |
Well, probably yes. We just need to make sure to apply them correctly |
65 |
in different contexts, to avoid accidentally skipping some constraints. |
66 |
I think it would be reasonably to assume that: |
67 |
|
68 |
a. flags masked/forced on LHS of implications (foo?) are evaluated |
69 |
in place, i.e. either always require RHS or remove it completely: |
70 |
|
71 |
foo? ( bar ) -> with foo forced, bar is always required |
72 |
=> we should also force bar |
73 |
|
74 |
b. flags masked/forced inside ^^, ??, || alter the contents/meaning -- |
75 |
in particular they might replace the whole construct with a single flag |
76 |
or make it unsolvable: |
77 |
|
78 |
^^ ( foo bar baz ) -> with foo forced, [bar baz] are never allowed |
79 |
=> we should mask them |
80 |
|
81 |
|| ( foo bar baz ) -> with foo forced, the constraint can be skipped |
82 |
|
83 |
c. flags masked/forced otherwise can't be altered: |
84 |
|
85 |
foo? ( bar ) -> with bar forced, we can skip the constraint. |
86 |
-> with bar masked, foo should be masked as well |
87 |
|
88 |
Does that cover all the contexts? |
89 |
|
90 |
-- |
91 |
Best regards, |
92 |
Michał Górny |