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

[Alexis Ballier]

On Mon, 29 May 2017 23:23:55 +0200
Michał Górny <mgorny@g.o> wrote:

> On pon, 2017-05-29 at 20:00 +0200, Alexis Ballier wrote:
> > On Mon, 29 May 2017 17:33:13 +0200
> > Michał Górny <mgorny@g.o> wrote:
[...]
> > > It can also be used with multi-flag ??, ^^ and || constraints,
> > > i.e.:
> > >
> > > - ?? means that at most one of the flags can be enabled. If user
> > > configuration causes more than one of the flags to be enabled,
> > > additional flags are implicitly disabled (masked) to satisfy
> > > the constraint.
> > >
> > > - || means that at least one of the flags must be enabled. If user
> > > configuration causes none of the flags to be enabled, one of them
> > > is enabled implicitly (forced).
> > >
> > > - ^^ means that exactly one of the flags must be enabled. The
> > > behavior is a combination of both above constraints.
> > >
> > > The automated solving of USE constraints would require the
> > > developers to consider the implicit effect of the constraints
> > > they are writing.
> >
> >
> > Can you provide an efficient algorithm for the above syntax?
> > That is, given a set of +/- useflags forced by user, output the set
> > of effective useflags (or a rant if it is inconsistent).
>
> I'd rather leave that to people who are good with algorithms. I find
> the whole thing scary but I don't really see a sane alternative here.

Well, Ciaran is a bit extreme with his implementation thing, but
he's right in the sense that here you're really repeating the same
mistakes that you're trying to fix. REQUIRED_USE was invented the same
way: Let's add some nice syntax to express dependency between useflags.
Ship it. Oh crap, this requires to solve SAT. Well, nothing good can be
done here, let's spit out to the user to chose for herself.
With your proposal, it seems to me you're simply postponing the problem
but not fixing it: Instead of spiting that one has to enable some
useflags, you'd spit that one has to specify how to solve the
constraint by expressing some preference. In the end, this'll add
another layer of complexity in both PM and the user configuration but
would not solve the root of the problem which is that no-one knows how
to automatically find a solution to those constraints and PM can't take
any action without user input.

You can't get away with "There is a solution but I'll leave that to
people who are good with algorithms": That is roughly the definition of
NP. If the person writing a proposal for a new feature (which is thus
supposedly the one person that has thoroughly thought the problem) can't
at least roughly draft how to implement it, that doesn't give much faith
in that it can be done properly. It certainly does not mean said person
is not good with algorithms but rather that the problem is very likely
to be a hard one. Not hard as in you need a Ph.D. in algorithms to
solve it but the kind of hardness almost every cryptographic algorithm
used today, and in the foreseeable future, relies on.

> Worst case, we have to figure out some arbitrary limitations to keep
> things sane.

The main point of my reply was (and still is) to find such limitations.
It is not as arbitrary as you may think and requires to be properly
understood so that we have to sacrifice the least expressivity power. A
good way to understand what a proper limitation would be is to try to
solve the problem.

> > Maybe I'm mistaken, but I doubt it is possible with n-ary
> > constraints.
> >
> > Now the extra question: Do those n-ary operators have any
> > advantage ?
>
> 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.

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 point is to express some preference, below you suggest to leave
> > that to the user, but what about leaving that to the ebuild
> > developer?
>
> Well, I don't find that a killer feature but I don't see a reason to
> take it away either. Either way we have some risks, especially when
> USE dependencies and blockers are involved. In both scenarios, I find
> it less risky to let user control the order than to rely on all
> developers respecting the same preference order. Not saying the
> latter wouldn't hurt anyway but the users would at least have an easy
> way out.

They already have an easy way out if you strip that part out of your
proposal: emerge will show some automatically enabled useflags; users
will notice and will fill package.use to disable the automatically
enabled useflag if they don't want it.

> > That way, e.g., || can be rewritten as implications: '|| ( a b c )'
> > becomes '!b? !c? a' meaning if none is enabled then a is
> > automatically enabled.
>
> Unless you are planning to cache the rewritten forms, I don't see
> a problem, really. You just reorder the flags according to the
> apparent preference before rewriting.

It's not a problem of rewriting or caching the result but a problem of
having a deterministic way to auto-enable required useflags.

Bests,

Alexis.