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