On Tue, 30 May 2017 10:29:48 +0200 Michał Górny <mgo...@gentoo.org> wrote: > That's why I'm sending this to the mailing list as a RFC, not a > proposal to vote on. It solves a defined set of problems, and gives > other chance to improve it and turn it into a complete solution. It's > not like it's going anywhere before it's implemented as a PoC and > tested.
Nobody's blaming you for that, rather the contrary :) > > > Yes, they do. They improve readability, compared to cascades of > > > plain constraints. I'm pretty sure users will be happier to see > > > 'you need to select one of foo, bar, baz' than 'if foo is > > > disabled, then ...' > > > > If the point is to automatically propose a solution, then who cares > > about readability? Users won't even see that message. > > But users should be able to reasonably figure out what happened, > exactly. There's a difference in quality between the two messages: > > a. 'foo is enabled; bar, got disabled', > > b. 'one of foo, bar, baz had to be enabled => you chose foo'. > > Not saying you can't figure it out. Saying in a more complex case, > grouping constraints like this is helpful. Why not then. You're right it makes more sense. > > Note that there are plenty of ways to add determinism in your > > proposal, but it *has* to be specified otherwise PM can't rely on > > it. For instance, you can say that in an unsatisfied || block then > > the left-most useflag is automatically enabled. || then becomes some > > syntactic sugar around unary operators: || ( a ... ) becomes > > equivalent to '!...? ( a )'. You can do the same for other > > operators. > > > > > > Sidenote: I just realized '|| ( a b c )' with left-most preference > > might be better since we are not dealing with binary variables but > > ternary ones (user disabled, user enabled, unspecified). 'USE="" || > > ( a b c )' should evaluate to 'a', 'USE="-a" || ( a b c )' should > > evaluate to 'b'. I don't see how to rewrite that with pure > > implications. > > The ternary concept is not exactly in line with how we handle USE > flags now. It's more like multi-layer binary. My proposal solved the > problem you were trying to solve via establishing priorities -- I > find it simpler to reorder the flags and use binary logic than to > invent a more complex logic to solve the same problem. I've re-read your proposal entirely and I don't see where you describe how to establish priorities. You describe how users can specify those, but nowhere do I see any default priority being mandated. If you describe and mandate it, then all is good I think. As I said, there are plenty of ways to solve the problem but it has to be mandated otherwise you're just postponing issues, not solving them. Alexis.
