This is kinda complementary to GLEP73, except that GLEP73 only stated that specific constructs are not supported for automatic enforcement. However, given the discussions around the topic, we may consider banning more of the 'weird' constructs in REQUIRED_USE. Possible ban targets: 1. Empty groups -- some of them are confusing (exactly one of zero items is true), most of the time they indicate that something stopped working (i.e. a function produces zero items) and I don't think we have a really valid use case for them. 2. Other groups nested inside ||/^^/?? groups -- unreadable and ambiguous. 3. All-of groups -- which made sense only in ||/^^/?? but see above. I think most of this stuff was indirectly inherited from || in dependencies without considering how it should apply to REQUIRED_USE in general, and to the additional group types involved in it.
As pointed out by ulm, we should probably also look into || groups in *DEPEND. AFAIU the current confusing behavior of || () being satisfied boils down to the possibility of '|| ( a? ( ... ) b? ( ... ) )' collapsing to empty group with USE='-a -b'. Given that, I see two possible change routes: 1. We ban empty || and USE flag conditionals inside || entirely. This will be consistent and may improve readability and correctness of some ebuilds that achieve suspicious results using foo? in ||. 2. We ban explicit empty || and make indirect || evaluate to false (effectively banning it as well). If we go this route, we will require a QA check that will detect || containing only USE conditionals, and requiring appropriate REQUIRED_USE.
Following further discussion on the topic, I think we'll actually leave PMS as-is and establish the bans on policy level. However, let's keep this open to see how well can GLEP73 be described without the explicit restrictions.
Looks like I was word enforcing REQUIRED_USE quite reasonably without this, so we probably won't need it after all.
(In reply to Michał Górny from comment #3) > Looks like I was word enforcing REQUIRED_USE quite reasonably without this, > so we probably won't need it after all. Can this bug be closed then?
