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

[Alexis Ballier]

On Tue, 30 May 2017 10:29:48 +0200
Michał Górny <mgorny@g.o> 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.