On wto, 2017-05-30 at 17:33 +0200, Alexis Ballier wrote: > 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. >
I'm not saying it's the most optimal algorithm of verifying the correctness of the constraints. It's just the one that's quite obvious -- relatively simple and reliable. If someone can come up with something better that covers at least the most common cases, I'm all for it. That said, this wouldn't be that much of a problem if we can keep the n low. For a start, we can rule out all flags that don't appear in REQUIRED_USE at all. Furthermore, I think we could also ignore the constraints for flags that don't appear there at least 'twice', and so on. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
