1 |
On Sat, 10 Jun 2017 00:30:07 +0200 |
2 |
Michał Górny <mgorny@g.o> wrote: |
3 |
|
4 |
> Hi, everyone. |
5 |
> |
6 |
> As you may or may not know, PMS says rather little about REQUIRED_USE |
7 |
> [1,2]. The largest past of the definition is shared with other |
8 |
> dependency-like specifications [3]. |
9 |
> |
10 |
> Similarly to regular dependency specifications, PMS is rather lax in |
11 |
> nesting things. While this isn't a major problem for dependencies |
12 |
> where the syntax is limited to any-of, all-of and USE-conditional |
13 |
> groups (though it already may cause some confusion there), it allows |
14 |
> quite a bit of a mayhem with the full set of REQUIRED_USE clauses. |
15 |
> |
16 |
> We have five different kinds of clauses there: any-of, at-most-one-of, |
17 |
> exactly-one-of, all-of and USE-conditional. Furthermore, unlike |
18 |
> in dependency specifications, the last type is circular with flags |
19 |
> enforced by REQUIRED_USE constraints. |
20 |
> |
21 |
> While nesting all of those clauses is technically valid (and can be |
22 |
> logically verified), it has no proven usability. As a result, it is |
23 |
> either not used at all or has a few use cases which suffer from poor |
24 |
> readability and can be easily replaced with *much simpler* |
25 |
> constraints. In fact, allowing them is not solving any issues but |
26 |
> only introducing more when developers fail at using them. |
27 |
> |
28 |
> I would therefore like to discuss restricting nesting of REQUIRED_USE |
29 |
> clauses. |
30 |
> |
31 |
> |
32 |
> What's my take in this? As you have probably noticed (and stopped |
33 |
> reading) I am working with Alexis on solving REQUIRED_USE constraints |
34 |
> automatically. We're working towards a few goals: keeping things |
35 |
> simple, giving predictable solutions, and being able to automatically |
36 |
> validate whether the constraints are solvable. |
37 |
> |
38 |
> While we're near solving almost everything, the complex clauses add |
39 |
> unnecessary complexity (both to the spec and to the code) which does |
40 |
> not really benefit anyone, and bring solutions that can not be |
41 |
> predictable because the clauses are ambiguous by design. |
42 |
> |
43 |
> To avoid adding this complexity, it would be reasonable to ban at |
44 |
> least some of the non-useful combinations. This means either banning |
45 |
> them completely (in a future EAPI + possibly repoman) so that |
46 |
> developers do not even try to use them, or disabling autosolving when |
47 |
> they are being used). |
48 |
|
49 |
I'm not sure it is worth restricting too much in the spec, at least now. |
50 |
It certainly has benefits, but the extra complexity they add forces to |
51 |
thoroughly think about how to design the proper solver, which I don't |
52 |
see as a bad thing. |
53 |
|
54 |
The main problem is that the solver, in those complex cases, will |
55 |
provide results that, at least to me, do not seem natural. |
56 |
|
57 |
It'd probably be a very good thing to restrict the allowed nesting |
58 |
since they add (runtime) complexity to the solver & checker, like a |
59 |
repoman warning and/or error, depending on some threshold. |
60 |
|
61 |
On the other hand, the syntax you propose seems way much saner. I like |
62 |
it and consider it is a good way to guide developers into writing |
63 |
easily predictable constraints. However, I would not disable auto |
64 |
solving when this does not match, I would have a generic algorithm, and |
65 |
wait for field testing before deciding if people are happy with the |
66 |
results or if they prefer to rewrite their constraints in a saner way |
67 |
to have a straightforward interpretation of the solver results. |
68 |
|
69 |
Bests, |
70 |
|
71 |
Alexis. |