1 |
On śro, 2017-05-31 at 10:38 +0200, Alexis Ballier wrote: |
2 |
> > > What if I specifically set USE=-bar in make.conf ? Do we really |
3 |
> > > want PM to override that without telling me ? |
4 |
> > |
5 |
> > Yes. Unless you specifically and explicitly disable that (globally or |
6 |
> > for USE=bar), in which case the PM would just reject to proceed. |
7 |
> |
8 |
> |
9 |
> Then could you please explain how to get the list of useflags the |
10 |
> solver is allowed to toggle ? Preferably in a PMS-friendly way (aka no |
11 |
> USE=foo emerge). It's not clear to me what this would be and is |
12 |
> mandatory for determinism. |
13 |
> |
14 |
> Note that most definitions are acceptable, but there must be one. |
15 |
|
16 |
If we *really* want to set this for the users, it would simply be |
17 |
a variable defined in make.profile, e.g.: |
18 |
|
19 |
REQUIRED_USE_STRICT="foo bar" |
20 |
|
21 |
which would mean the solver is globally forbidden from touching those |
22 |
flags, i.e. if the solution would involve touching them, PM must fail |
23 |
and request user to manually resolve it. |
24 |
|
25 |
However, as far as I'm concerned we'd be good at keeping this purely as |
26 |
user configuration, alike FEATURES=i-do-not-want-automatic-solving. |
27 |
|
28 |
> > > I believe that, from the ebuild POV, the ternary useflag model is |
29 |
> > > more appropriate: You have a whole bunch of ways to specify |
30 |
> > > useflags with portage (make.conf, package.use, profiles, command |
31 |
> > > line, ...). From the ebuild those are collapsed into 'user input'. |
32 |
> > > You only have IUSE (with its defaults) and that's what the |
33 |
> > > auto-solver should play with: those are the flags that can be |
34 |
> > > toggled. |
35 |
> > |
36 |
> > I see your point. However, it's merely a preference problem and we |
37 |
> > really don't want the constraints to become ternary and/or PM try to |
38 |
> > force the reverse solutions. That's an easy way to lose |
39 |
> > predictability. |
40 |
> |
41 |
> They're not ternary anymore after processing ebuild: IUSE="foo +bar" |
42 |
> means instantiate foo as -foo if not specified, and bar as +bar. |
43 |
> The way I see it, ternary model is useful in the sense that the 3rd |
44 |
> undefined state is what the solver can toggle, the others are fixed |
45 |
> (either by user input or e.g. use.mask). |
46 |
> |
47 |
> Basically, I see automatic solving of REQUIRED_USE as dynamic IUSE |
48 |
> defaults. But see above, this might not be the best way. |
49 |
|
50 |
I'm lost on what you're trying to achieve here. Maybe give a full run- |
51 |
out based on Portage behavior -- i.e. involving all the places USE flags |
52 |
can be altered in Portage, and how they're going to affect the result. |
53 |
Don't forget about USE_ORDER. |
54 |
|
55 |
> > Besides, I should point out that USE_EXPAND in make.profile |
56 |
> > and make.conf are strictly binary. |
57 |
> |
58 |
> Last I checked IUSE="+use_expand_foo use_expand_bar" worked just as |
59 |
> useflags. |
60 |
|
61 |
I'm talking about FOO="bar baz" form which implies -* for all remaining |
62 |
values (and does not accept '-flag', unless I'm mistaken). |
63 |
|
64 |
> |
65 |
> > > > Now, this also means that every constraint that can't be solved in |
66 |
> > > > this easy fashion is invalid. We want to detect that, and warn the |
67 |
> > > > developer. Some of those could be tricky. Simple example: |
68 |
> > > > |
69 |
> > > > foo? ( baz ) bar? ( !baz ) |
70 |
> > > > |
71 |
> > > > This one is invalid because USE='foo bar' requires both 'baz' and |
72 |
> > > > '!baz' as a solution. Remember that we don't want to do any |
73 |
> > > > changes besides what's explicitly written there, no guessing. |
74 |
> > > |
75 |
> > > Besides that, what makes it invalid ? |
76 |
> > |
77 |
> > What makes it invalid is that you can't solve it in a predictable way. |
78 |
> |
79 |
> You can fail in a predictable way and ebuild writer can adjust it to |
80 |
> avoid that. |
81 |
|
82 |
If the point is to process constraints *automatically*, then failing is |
83 |
not the desired result. Yes, we can consider that a minor issue/warning |
84 |
level but it is still an issue. I named it 'invalid' because it prevents |
85 |
the automatic solving from working which is the purpose of this whole |
86 |
effort. |
87 |
|
88 |
> Again, you *need* to process the constraints in order. '!a? |
89 |
> ( b ) !b? ( a )' is not deterministic when none of a and b are |
90 |
> enabled otherwise. |
91 |
|
92 |
You can't rely on any particular order of constraints, especially when |
93 |
eclass stacking comes into play. You could try defining some constraint- |
94 |
sorting algorithm but it's going to be complex and it's usefulness will |
95 |
be limited anyway due to various kinds of grouping. |
96 |
|
97 |
> You'll get a message like: |
98 |
> " |
99 |
> The constraint bar? ( !baz )' is violated. |
100 |
> bar is enabled because $reason (say, make.conf) |
101 |
> baz is enabled because of the constraint 'foo? ( baz )' |
102 |
> foo is enabled because $reason |
103 |
> " |
104 |
|
105 |
You = user or ebuild author? Because per my proposal, this construct |
106 |
should result in QA error/warning, telling the ebuild writer to use |
107 |
predictable constraints. |
108 |
|
109 |
Of course, we could still accept the ebuild and just fail hard on user |
110 |
side (alike REQUIRED_USE). But that's really getting out of scope. |
111 |
|
112 |
> |
113 |
> > > How is it more invalid than '?? ( foo bar )' ? |
114 |
> > |
115 |
> > This would go into: |
116 |
> > |
117 |
> > foo? ( !bar ) |
118 |
> |
119 |
> Just to be clear: Are you suggesting banning '??' from the syntax or |
120 |
> simply an internal rewrite for the solver ? |
121 |
|
122 |
'Internal rewrite', i.e. how '??' would have to be interpreted. |
123 |
|
124 |
> |
125 |
> > which gives a single predictable solution: |
126 |
> |
127 |
> Then ebuild writer should not write 'foo? ( baz ) bar? ( !baz )' but |
128 |
> rather: 'foo? ( !bar baz ) bar? ( !baz )', which should cover more |
129 |
> cases. With USE="foo bar", the message would then be: |
130 |
> " |
131 |
> The constraint 'foo? ( !bar )' is violated. |
132 |
> foo is enabled because $reason |
133 |
> bar is enabled because $reason |
134 |
> " |
135 |
> which is similar to the above except there's one less step for |
136 |
> explaining the reasons. It's not dramatic but it is, indeed, desirable |
137 |
> to have simple & clear reasons. I'd say that's more to the argument for |
138 |
> specifying completely how to solve that and leave those small |
139 |
> improvements to ebuild writers and/or QA. |
140 |
|
141 |
Is this message meant to be disabled for the purpose of explaining |
142 |
automatic decisions, or as an error? |
143 |
|
144 |
Also, your example (unlike the one I gave in the original mail) prefers |
145 |
foo over bar. That's the only difference. |
146 |
|
147 |
> |
148 |
> [...] |
149 |
> > > > However, the |
150 |
> > > > following should be valid: |
151 |
> > > > |
152 |
> > > > foo? ( baz ) bar? ( !foo !baz ) |
153 |
> > > > |
154 |
> > > > Because now we clearly indicate that USE=bar disables USE=foo, |
155 |
> > > > and therefore makes the first constraint inapplicable. It clearly |
156 |
> > > > indicates course of action for all combinations: |
157 |
> > > |
158 |
> > > Ok, I now think you're aiming for giving full power to the solver, |
159 |
> > > overriding user inputs if necessary. Before going further, I think |
160 |
> > > we should first agree on what are the useflags such a solver can |
161 |
> > > toggle. I'm not sure 'USE=foo emerge blah' should disable foo |
162 |
> > > instead of failing for example. |
163 |
> > > |
164 |
> > |
165 |
> > As I said, it's a matter of configuration to decide which flags should |
166 |
> > be touched, and which not. Of course if we find that necessary, we may |
167 |
> > go into defining a specific set in the profiles or metadata. |
168 |
> > |
169 |
> > However, I would rather focus on getting a PoC solver and checker |
170 |
> > first, and play with existing constraints to see how it all works. |
171 |
> |
172 |
> The solver seems on good tracks, at least from the algorithmic POV. The |
173 |
> checker, however, is not clear at all to me. The main reason is that to |
174 |
> determine if the solver will be able to solve it, it needs to know what |
175 |
> the solver can toggle and what not. |
176 |
> |
177 |
|
178 |
The point would be: by definition, the solver should be able to touch |
179 |
*any* USE flag. If it can't, it mostly implies that you can't use |
180 |
the automatic solver, and so the case is irrelevant for checking. |
181 |
Attempting to go beyond that is going to give a lot of complexity |
182 |
and most likely kill the whole idea. |
183 |
|
184 |
One thing we need to worry about are masks. We need to think about them. |
185 |
|
186 |
-- |
187 |
Best regards, |
188 |
Michał Górny |