Re: [gentoo-dev] Pre-GLEP RFC: Automated enforcing of REQUIRED_USE constraints

[Alexis Ballier]

On Sat, 08 Jul 2017 11:43:39 +0200
Michał Górny <mgorny@g.o> wrote:

> Hi, everyone.
>
> I think the affairs have settled enough and I've finished filling
> in the pre-GLEP for REQUIRED_USE auto-enforcing. It's got all
> the algorithms, rationale and separated reference implementation.
>
> If there are no major concerns raised, I will soon start working
> on writing an optimized implementation for pkgcore/pkgcheck
> and integrating the verification algos with the CI.
>
> The pre-GLEP for review is here:
>
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:ReqUse


Constraint group reordering algorithm

I really think we should only consider REQUIRED_USE with forced/masked
useflags instantiated there. And ban (in repoman) REQUIRED_USE that
contain some "False": "a? ( b )" with 'a' free and 'b' masked is
perfectly ok now but it hides a serious problem in the package/profile.
Instantiating this would give: "a? ( False )" and be an error
just like we have depend.bad & co. This is independent of auto
solving or not, it's already wrong.

Reordering is a dangerous path as we've already seen since it can
create unexpected loops for the solver.

Working on instantiated REQUIRED_USE constraints would probably
simplify quite a bit your GLEP too: you already have the "Verifying
that the constraints do not alter immutable flags" part that roughly
does the same thing as instantiating, except if you assume it's already
true you can skip the reordering.


--------


Concept for transforming REQUIRED_USE into implications

Ok, now I probably understand better the concept of common prefix. I'm
definitely biased here, but I would feel better with a more recursive
presentation of it. Assume we have 'validate(list of clauses)';
basically, the common prefix idea is that for an implication 'foo?
( consequences = list of clauses )' you first validate the consequences
as if it were a REQUIRED_USE (so that the subtree rooted at foo is
not self-conflicting) and then consider the whole thing as a clause.
The idea would then be to have similar checks as to what you've written
but working on trees (ASTs) instead of flattened clauses. This would
avoid having to deal with unique identities (these would come for free)
and IMHO would be easier to understand.
I'm not sure how to do this though, I'll ping you when I have some idea.

One big advantage of working on ASTs is that it becomes trivial to
suggest a proper reordering.

-------

Restrictions on REQUIRED_USE format

I still fail to see the point here. One can simply apply the rewriting
you suggest below and be done with it. Rationale is not very convincing
to me:

- avoiding unpredictable results of automatic flag adjustments:
	A deterministic algorithm is, by definition, predictable.
- improving readability of REQUIRED_USE constraints:
	No need for a restriction for that. If people want to shoot
	themselves in the foot, it is not a PMS problem. I see that
	like proposing death penalty for those who commit suicide :)
- keeping the specification and implementation relatively simple:
	You already define everything for working without restriction.
	Plus, unlimited implication nesting has the same complexity.

-------


Do you have numbers on the checker run on all inputs from gentoo-x86 ?
Since we're dealing with heuristics those are particularly important to
validate we're not rejecting too many constructs.


Alexis.