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

[Alexis Ballier]

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

> Hello,
>
> For a long time we seem to be missing appropriate tools to handle USE
> flag constraints efficiently. EAPI 4 brought REQUIRED_USE but all
> things considered, it has proven to be far from an optimal solution.
> I would therefore like to discuss adding a better tool to amend or
> replace it, to allow for automated handling of USE flag constraints.


This has been discussed in the past and I'm basically all for it. Some
more detailed comments below.

[...]
> 2. Specification
> ================
>
> 2.1. Forced USE flag constraints
> ================================
>
> This proposal introduces USE flag constraints that are meant to be
> solved automatically by the package manager. This is somewhat similar
> to REQUIRED_USE, except that it does not require the user to take any
> explicit action. In that regard, it is closer to conditional
> package.use.force/mask.
>
> In the basic form, it can be used to conditionally force a specific
> flag to be enabled or disabled. For example:
>
>   foo? ( bar )
>
> would mean that the bar flag is implicitly enabled (forced) if foo is
> enabled as well. Appropriately:
>
>   foo? ( !bar )
>
> would mean that the bar flag is implicitly disabled (masked) in that
> case.

All good here.


> 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).
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 ?
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?
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.

Note that with only unary constraints, computing the set of effective
useflags becomes trivial (linear in the # of useflags + constraints):
take the constraints as a list, solve the first one, add its
consequences (if any) to the set of forced useflags, continue with next
constraint or rant if the set of forced flags is inconsistent.


> 2.2. UI implications
> ====================
[...]

I really like that part. It becomes even simpler with only unary
constraints :)

[...]
> 2.4. Backwards compatibility
> ============================
>
> Before choosing the exact way of implementing this, we need to answer
> how far we want to provide backwards compatibility. In particular:
>
> a. Do we need the REQUIRED_USE requiring explicit user selection? Or
> can we rely completely on other solutions (automatic solving,
> pkg_pretend())?
>
> b. Would changing REQUIRED_USE behavior in place cause unintended side
> effects? Are we going to accept those effects until the packages are
> fixed? (e.g. selecting less preferred solution of constraint)


I would prefer changing REQUIRED_USE in a new EAPI. We definitely do
not need a new variable, REQUIRED_USE is good enough, but PMS has been
vague enough not to define that so we can't assume the selection of
auto-enabled useflags will be what was meant rather than something
completely stupid.

I'm even more inclined towards changing that in a new EAPI since using
the current REQUIRED_USE syntax seems to introduce yet another
exponential algorithm in the critical path of 'emerge -uDN world'...

[...]
> 2.5. Ebuild interface
> =====================
>
> This section is most flexible as I don't really care how it's done,
> as long as it's done. Depending on our preferences, and the answers to
> questions in the preceding section, the options include:
>
> 1. changing behavior of REQUIRED_USE retroactively -- i.e. making
> Portage start solving USE constraints automatically, and being able to
> rely on that a few months from now,
>
> 2. changing behavior of REQUIRED_USE in a future EAPI,
>
> 3. adding ENFORCED_USE with the new behavior in a future EAPI
> (and either keeping or removing REQUIRED_USE),
>
> 4. adding special syntax to REQUIRED_USE to indicate which constraints
> can be solved automatically,
>
> 5. adding special syntax to IUSE to indicate which flags can be
> enabled or disabled automatically via REQUIRED_USE (a little
> different from the exact proposal),
>
> 6. adding a dedicated variable to indicate USE_EXPAND sets that can be
> solved automatically via REQUIRED_USE (partial solution).


In that order:
2
1
4
_reopen_nominations
3 5 6


[...]
> 4. Comments
> ===========
>
> What do you think?

+1

Alexis.