On Mon, 29 May 2017 23:23:55 +0200 Michał Górny <[email protected]> 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 <[email protected]> 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. > Worst case, we have to figure out some arbitrary limitations to keep > things sane. The main point of my reply was (and still is) to find such limitations. It is not as arbitrary as you may think and requires to be properly understood so that we have to sacrifice the least expressivity power. A good way to understand what a proper limitation would be is to try to solve the problem. > > 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 ? > > 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. 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 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.
