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

[Michał Górny]

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