Re: [gentoo-dev] [RFC] Forced/automatic USE flag constraints (codename: ENFORCED_USE)

[Alexis Ballier]

On Tue, 30 May 2017 16:33:32 +0200
Michał Górny <mgorny@g.o> wrote:

[...]
> The problem is: how far is that going to work? That's what I would
> like to try determining in the first place.
>
> I'm most worried about complex constructs like:
>
>   foo? ( bar ) ^^ ( baz bar )

The order in which it is written will matter:
Assuming user has enabled 'foo', first process 'foo? ( bar )', which
gives you "USE='foo bar'". Then process '^^ ( baz bar )'; all good,
we're done.

If user has enabled 'foo baz' then there is a problem and it is
normal to rant.

> But I do not have any obvious ideas how to express them safely while
> preserving readability and relative simplicity of the constructs, i.e.
> not having to write a big mapping table.
>
> Especially if we are to allow having a preference on baz, the mapping
> for ^^ alone would be:
>
>   !bar !baz -> !bar  baz
>    bar !baz ->  bar !baz  [valid]
>   !bar  baz -> !bar  baz  [valid]
>    bar  baz -> !bar  baz
>
> With the additional foo constraint, it becomes harder but not
> impossible. However, with more constraints we may reach a dead end.

You already made a convincing argument that || & co are good things to
have, that's not to write the combinatorics of the whole thing as
implications!

Moreover, you can use implications and the processing order as hints: If
you believe 'if foo and bar are enabled then baz should most likely be
enabled even if the latter '|| ( bay baz )' would select 'bay' and not
'baz'' you prepend required_use by 'foo? bar? baz' and are done with it.


> Of course, we could just validate all the possible cases via repoman,
> and reject the ebuild if there's at least one conflict between them.
> Not sure how to express that properly in the spec though. Not sure
> how it would work practically.

Adding a 2^n check to repoman isn't gonna work well.


[...]