On wto, 2017-05-30 at 14:00 +0200, Ulrich Mueller wrote: > > > > > > On Tue, 30 May 2017, Alexis Ballier wrote: > > The way I see it, this boils down to spec'ing something that > > guarantees there's a unique solution given an input. The solution > > does not have to be good or bad (we don't have a good metric on that > > anyway), it just has to be deterministic so that developers can > > arrange their REQUIRED_USE constraints to have PM chose the proper > > solution. > > Right. As I see it, the problem we must solve is that for k USE flags > there are 2**k possible combinations, but there may be only n > combinations that are valid, with n < 2**k. For example, for > IUSE="foo bar baz" there are 2**3 = 8 possible combinations, but with > REQUIRED_USE="|| ( foo bar baz )" or "^^ ( foo bar baz )" only 7 or 3 > of them are valid, respectively. > > Now we can either just specify which of the combinations are valid; > this is what REQUIRED_USE currently does. Or we can specify a complete > mapping from every invalid input combination of flags to a valid > output combination. I think we should do the latter. >
Well, you have a point. My proposal was to do the latter, reusing the syntax from the former. Strictly speaking, the following REQUIRED_USE are equivalent: foo? ( bar ) (1) !bar? ( !foo ) (2) However, the developers already select between the two to suggest a specific solution to the user. (1) is used to suggest that enabling the 'bar' flag is the more obvious solution; (2) is used to suggest that disabling 'foo' would be most likely preferred. If we stick to that, I think we can easily achieve the latter goal without sacrificing much of readability and/or making things much harder for developers. That is, treating the '?' as implication: foo? ( bar ) -> foo implies bar !bar? ( !foo ) -> !bar implies !foo 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 ) 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. 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. As I said, it's an early RFC to figure out any tips before starting to investigate the technical mysteries. Probably worth to look into existing REQUIRED_USE uses and put them into some trivial constraint solver. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
