diff options
| author |   Michał Górny <mgorny@gentoo.org> | 2017-07-09 07:25:14 +0000 |
|---|---|---|
| committer | Michał Górny <mgorny@gentoo.org> | 2017-07-09 07:25:14 +0000 |
| commit | c6583728514be7c16965fa07ee8503f331188ce1 (patch) | |
| tree | 07cacff229a370f8adf45eaea6b5e7f35e0eee8a | |
| parent | /* Restrictions on REQUIRED_USE format */ disallow empty ||/??/^^, per the di... (diff) | |
| download | glep-c6583728514be7c16965fa07ee8503f331188ce1.tar.gz glep-c6583728514be7c16965fa07ee8503f331188ce1.tar.bz2 glep-c6583728514be7c16965fa07ee8503f331188ce1.zip | |
/* Restrictions for allowed REQUIRED_USE syntax */ ban on empty groups
| -rw-r--r-- | GLEP:73.mw | 15 |
1 files changed, 15 insertions, 0 deletions
@@ -348,6 +348,21 @@ The only use case in Gentoo was in media-video/mpv: It indicates that the OpenGL video output requires selecting one of the variants, with the ''libmpv'' variant being allowed only without CLI enabled. While this may be technically valid, it is confusing. Furthermore, other REQUIRED_USE constraints already require that either ''cli''' or ''libmpv'' is enabled, making ''!cli'' imply ''libmpv''. Therefore, the USE-conditional in the constraint is redundant. +====Empty any-of, at-most-one-of, exactly-one-of groups==== + +As the first mailing list review indicated, the PMS explicitly specifies a special case that empty any-of, at-most-one-of and exactly-one-of groups all evaluate to true. + +This behavior has been explained as a historical behavior associated with Portage removing unmatched USE-conditional groups inside any-of dependency groups which could result in the group becoming effectively empty. As REQUIRED_USE was introduced, the rule was effectively extended into the new operators. + +It is unclear whether this is the most correct behavior logically though. Alexis Ballier pointed out: + +: I mean, in every context I've ever seen, applying a rule to the empty set is the neutral of that rule, so that it preserves associativity. +: That'd mean: <code>|| ( )</code> is false, <code>&& ( )</code> is true, <code>^^ ( )</code> is false, <code>?? ( )</code> is false. + +(the thread afterwards develops that the more correct result for <code>?? ( )</code> could be to be true) + +Since the original use case does not apply here (USE-conditional groups are banned inside those operators), the correct behavior is unclear and this has no real use case, banning it seems like the best course of action. + ===Solving algorithm=== The solving algorithm attempts to enforce REQUIRED_USE in the most natural way, interpreting the constraints as developer suggestions on how to make the constraint apply. |