| 1 |
On wto, 2017-05-30 at 17:33 +0200, Alexis Ballier wrote: |
| 2 |
> On Tue, 30 May 2017 16:33:32 +0200 |
| 3 |
> Michał Górny <mgorny@g.o> wrote: |
| 4 |
> |
| 5 |
> [...] |
| 6 |
> > The problem is: how far is that going to work? That's what I would |
| 7 |
> > like to try determining in the first place. |
| 8 |
> > |
| 9 |
> > I'm most worried about complex constructs like: |
| 10 |
> > |
| 11 |
> > foo? ( bar ) ^^ ( baz bar ) |
| 12 |
> |
| 13 |
> The order in which it is written will matter: |
| 14 |
> Assuming user has enabled 'foo', first process 'foo? ( bar )', which |
| 15 |
> gives you "USE='foo bar'". Then process '^^ ( baz bar )'; all good, |
| 16 |
> we're done. |
| 17 |
> |
| 18 |
> If user has enabled 'foo baz' then there is a problem and it is |
| 19 |
> normal to rant. |
| 20 |
> |
| 21 |
> > But I do not have any obvious ideas how to express them safely while |
| 22 |
> > preserving readability and relative simplicity of the constructs, i.e. |
| 23 |
> > not having to write a big mapping table. |
| 24 |
> > |
| 25 |
> > Especially if we are to allow having a preference on baz, the mapping |
| 26 |
> > for ^^ alone would be: |
| 27 |
> > |
| 28 |
> > !bar !baz -> !bar baz |
| 29 |
> > bar !baz -> bar !baz [valid] |
| 30 |
> > !bar baz -> !bar baz [valid] |
| 31 |
> > bar baz -> !bar baz |
| 32 |
> > |
| 33 |
> > With the additional foo constraint, it becomes harder but not |
| 34 |
> > impossible. However, with more constraints we may reach a dead end. |
| 35 |
> |
| 36 |
> You already made a convincing argument that || & co are good things to |
| 37 |
> have, that's not to write the combinatorics of the whole thing as |
| 38 |
> implications! |
| 39 |
> |
| 40 |
> Moreover, you can use implications and the processing order as hints: If |
| 41 |
> you believe 'if foo and bar are enabled then baz should most likely be |
| 42 |
> enabled even if the latter '|| ( bay baz )' would select 'bay' and not |
| 43 |
> 'baz'' you prepend required_use by 'foo? bar? baz' and are done with it. |
| 44 |
> |
| 45 |
> |
| 46 |
> > Of course, we could just validate all the possible cases via repoman, |
| 47 |
> > and reject the ebuild if there's at least one conflict between them. |
| 48 |
> > Not sure how to express that properly in the spec though. Not sure |
| 49 |
> > how it would work practically. |
| 50 |
> |
| 51 |
> Adding a 2^n check to repoman isn't gonna work well. |
| 52 |
> |
| 53 |
|
| 54 |
I'm not saying it's the most optimal algorithm of verifying |
| 55 |
the correctness of the constraints. It's just the one that's quite |
| 56 |
obvious -- relatively simple and reliable. If someone can come up with |
| 57 |
something better that covers at least the most common cases, I'm all for |
| 58 |
it. |
| 59 |
|
| 60 |
That said, this wouldn't be that much of a problem if we can keep the n |
| 61 |
low. For a start, we can rule out all flags that don't appear |
| 62 |
in REQUIRED_USE at all. Furthermore, I think we could also ignore |
| 63 |
the constraints for flags that don't appear there at least 'twice', |
| 64 |
and so on. |
| 65 |
|
| 66 |
-- |
| 67 |
Best regards, |
| 68 |
Michał Górny |
Archives