On wto, 2017-05-30 at 09:42 +0200, Alexis Ballier wrote: > On Mon, 29 May 2017 23:23:55 +0200 > Michał Górny <mgo...@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 <mgo...@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
signature.asc
Description: This is a digitally signed message part
