1 |
On wto, 2017-05-30 at 09:42 +0200, Alexis Ballier wrote: |
2 |
> On Mon, 29 May 2017 23:23:55 +0200 |
3 |
> Michał Górny <mgorny@g.o> wrote: |
4 |
> |
5 |
> > On pon, 2017-05-29 at 20:00 +0200, Alexis Ballier wrote: |
6 |
> > > On Mon, 29 May 2017 17:33:13 +0200 |
7 |
> > > Michał Górny <mgorny@g.o> wrote: |
8 |
> |
9 |
> [...] |
10 |
> > > > It can also be used with multi-flag ??, ^^ and || constraints, |
11 |
> > > > i.e.: |
12 |
> > > > |
13 |
> > > > - ?? means that at most one of the flags can be enabled. If user |
14 |
> > > > configuration causes more than one of the flags to be enabled, |
15 |
> > > > additional flags are implicitly disabled (masked) to satisfy |
16 |
> > > > the constraint. |
17 |
> > > > |
18 |
> > > > - || means that at least one of the flags must be enabled. If user |
19 |
> > > > configuration causes none of the flags to be enabled, one of them |
20 |
> > > > is enabled implicitly (forced). |
21 |
> > > > |
22 |
> > > > - ^^ means that exactly one of the flags must be enabled. The |
23 |
> > > > behavior is a combination of both above constraints. |
24 |
> > > > |
25 |
> > > > The automated solving of USE constraints would require the |
26 |
> > > > developers to consider the implicit effect of the constraints |
27 |
> > > > they are writing. |
28 |
> > > |
29 |
> > > |
30 |
> > > Can you provide an efficient algorithm for the above syntax? |
31 |
> > > That is, given a set of +/- useflags forced by user, output the set |
32 |
> > > of effective useflags (or a rant if it is inconsistent). |
33 |
> > |
34 |
> > I'd rather leave that to people who are good with algorithms. I find |
35 |
> > the whole thing scary but I don't really see a sane alternative here. |
36 |
> |
37 |
> Well, Ciaran is a bit extreme with his implementation thing, but |
38 |
> he's right in the sense that here you're really repeating the same |
39 |
> mistakes that you're trying to fix. REQUIRED_USE was invented the same |
40 |
> way: Let's add some nice syntax to express dependency between useflags. |
41 |
> Ship it. Oh crap, this requires to solve SAT. Well, nothing good can be |
42 |
> done here, let's spit out to the user to chose for herself. |
43 |
> With your proposal, it seems to me you're simply postponing the problem |
44 |
> but not fixing it: Instead of spiting that one has to enable some |
45 |
> useflags, you'd spit that one has to specify how to solve the |
46 |
> constraint by expressing some preference. In the end, this'll add |
47 |
> another layer of complexity in both PM and the user configuration but |
48 |
> would not solve the root of the problem which is that no-one knows how |
49 |
> to automatically find a solution to those constraints and PM can't take |
50 |
> any action without user input. |
51 |
> |
52 |
> You can't get away with "There is a solution but I'll leave that to |
53 |
> people who are good with algorithms": That is roughly the definition of |
54 |
> NP. If the person writing a proposal for a new feature (which is thus |
55 |
> supposedly the one person that has thoroughly thought the problem) can't |
56 |
> at least roughly draft how to implement it, that doesn't give much faith |
57 |
> in that it can be done properly. It certainly does not mean said person |
58 |
> is not good with algorithms but rather that the problem is very likely |
59 |
> to be a hard one. Not hard as in you need a Ph.D. in algorithms to |
60 |
> solve it but the kind of hardness almost every cryptographic algorithm |
61 |
> used today, and in the foreseeable future, relies on. |
62 |
|
63 |
That's why I'm sending this to the mailing list as a RFC, not a proposal |
64 |
to vote on. It solves a defined set of problems, and gives other chance |
65 |
to improve it and turn it into a complete solution. It's not like it's |
66 |
going anywhere before it's implemented as a PoC and tested. |
67 |
|
68 |
> > Yes, they do. They improve readability, compared to cascades of plain |
69 |
> > constraints. I'm pretty sure users will be happier to see 'you need to |
70 |
> > select one of foo, bar, baz' than 'if foo is disabled, then ...' |
71 |
> |
72 |
> If the point is to automatically propose a solution, then who cares |
73 |
> about readability? Users won't even see that message. |
74 |
|
75 |
But users should be able to reasonably figure out what happened, |
76 |
exactly. There's a difference in quality between the two messages: |
77 |
|
78 |
a. 'foo is enabled; bar, got disabled', |
79 |
|
80 |
b. 'one of foo, bar, baz had to be enabled => you chose foo'. |
81 |
|
82 |
Not saying you can't figure it out. Saying in a more complex case, |
83 |
grouping constraints like this is helpful. |
84 |
|
85 |
> |
86 |
> Note that there are plenty of ways to add determinism in your proposal, |
87 |
> but it *has* to be specified otherwise PM can't rely on it. For |
88 |
> instance, you can say that in an unsatisfied || block then the |
89 |
> left-most useflag is automatically enabled. || then becomes some |
90 |
> syntactic sugar around unary operators: || ( a ... ) becomes equivalent |
91 |
> to '!...? ( a )'. You can do the same for other operators. |
92 |
> |
93 |
> |
94 |
> Sidenote: I just realized '|| ( a b c )' with left-most preference might |
95 |
> be better since we are not dealing with binary variables but ternary |
96 |
> ones (user disabled, user enabled, unspecified). 'USE="" || ( a b c )' |
97 |
> should evaluate to 'a', 'USE="-a" || ( a b c )' should evaluate to 'b'. |
98 |
> I don't see how to rewrite that with pure implications. |
99 |
|
100 |
The ternary concept is not exactly in line with how we handle USE flags |
101 |
now. It's more like multi-layer binary. My proposal solved the problem |
102 |
you were trying to solve via establishing priorities -- I find it |
103 |
simpler to reorder the flags and use binary logic than to invent a more |
104 |
complex logic to solve the same problem. |
105 |
|
106 |
> > > The point is to express some preference, below you suggest to leave |
107 |
> > > that to the user, but what about leaving that to the ebuild |
108 |
> > > developer? |
109 |
> > |
110 |
> > Well, I don't find that a killer feature but I don't see a reason to |
111 |
> > take it away either. Either way we have some risks, especially when |
112 |
> > USE dependencies and blockers are involved. In both scenarios, I find |
113 |
> > it less risky to let user control the order than to rely on all |
114 |
> > developers respecting the same preference order. Not saying the |
115 |
> > latter wouldn't hurt anyway but the users would at least have an easy |
116 |
> > way out. |
117 |
> |
118 |
> They already have an easy way out if you strip that part out of your |
119 |
> proposal: emerge will show some automatically enabled useflags; users |
120 |
> will notice and will fill package.use to disable the automatically |
121 |
> enabled useflag if they don't want it. |
122 |
> |
123 |
> > > That way, e.g., || can be rewritten as implications: '|| ( a b c )' |
124 |
> > > becomes '!b? !c? a' meaning if none is enabled then a is |
125 |
> > > automatically enabled. |
126 |
> > |
127 |
> > Unless you are planning to cache the rewritten forms, I don't see |
128 |
> > a problem, really. You just reorder the flags according to the |
129 |
> > apparent preference before rewriting. |
130 |
> |
131 |
> It's not a problem of rewriting or caching the result but a problem of |
132 |
> having a deterministic way to auto-enable required useflags. |
133 |
> |
134 |
> Bests, |
135 |
> |
136 |
> Alexis. |
137 |
> |
138 |
|
139 |
-- |
140 |
Best regards, |
141 |
Michał Górny |