I'd like to propose adding two new operators, or rather extending the existing USE dependency operators with an 'arrow' syntax to allow dependee flag name to be different.
Killer rationale: we have 2-style and 4-style USE dependencies. We inevitably need to have 8-style USE dependencies, and then we're good till EAPI 16.
The new USE dependency syntax I'd like to see is (square brackets indicate optional parts):
meaning 'if a is enabled (disabled) on this package, require b to be enabled (disabled) on the other package', and:
meaning the above + 'and vice versa'.
a?>b <=> a? ( ...[b] )
!a?>b <=> !a? ( ...[b] )
a?>-b <=> a? ( ...[-b] )
!a?->-b <=> !a? ( ...[-b] )
a=>b <=> a? ( ...[b] ) !a? ( ...[-b] )
!a=>b <=> !a? ( ...[b] ) a? ( ...[-b] )
a=>-b <=> a? ( ...[-b] ) !a? ( ...[b] )
!a=>-b <=> !a? ( ...[-b] ) a? ( ...[b] )
Naturally, the => forms are equivalent in pairs.
Equivalent same-flag forms
a? <=> a?>a
!a? <=> !a?>-a
a= <=> a=>a
!a= <=> !a=>-a
While they're obviously redundant, I believe that at least '!a?' is less readable (counter-intuitive) than the expanded form.
I can think of two primary USE cases for it.
Firstly, python-single-r1 ebuilds with new API could be simplified. Currently, they do:
pst1? ( ...[pt1] )
pst2? ( ...[pt2] )
With the new syntax, they could generate a PYTHON_MULTI_USEDEP having:
Secondly, static-enabled ebuilds. They currently do, usually via a gross hack:
static? ( dev-libs/foo[static-libs(+)] )
The new syntax would allow: