On Tue, 30 May 2017 16:33:32 +0200 Michał Górny <mgo...@gentoo.org> 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. [...]
