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

["Michał Górny" <mgorny@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 6803 bytes --]

On wto, 2017-05-30 at 09:42 +0200, Alexis Ballier wrote:
> On Mon, 29 May 2017 23:23:55 +0200
> Michał Górny <mgorny@gentoo.org> 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@gentoo.org> 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.

That's why I'm sending this to the mailing list as a RFC, not a proposal
to vote on. It solves a defined set of problems, and gives other chance
to improve it and turn it into a complete solution. It's not like it's
going anywhere before it's implemented as a PoC and tested.

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

But users should be able to reasonably figure out what happened,
exactly. There's a difference in quality between the two messages:

a. 'foo is enabled; bar, got disabled',

b. 'one of foo, bar, baz had to be enabled => you chose foo'.

Not saying you can't figure it out. Saying in a more complex case,
grouping constraints like this is helpful.

> 
> 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 ternary concept is not exactly in line with how we handle USE flags
now. It's more like multi-layer binary. My proposal solved the problem
you were trying to solve via establishing priorities -- I find it
simpler to reorder the flags and use binary logic than to invent a more
complex logic to solve the same problem.

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

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 988 bytes --]