On Sat, 08 Jul 2017 11:43:39 +0200 Michał Górny <mgo...@gentoo.org> 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.
