>>>>> On Mon, 2 Oct 2017, Kristian Fiskerstrand wrote:

> On 10/02/2017 09:58 PM, Rich Freeman wrote:
>> Does the PMS actually define what the correct behavior is for this
>> syntax?

> it evaluates to a true, i.e always valid/resolved. And although
> explicitly naming an empty group in an ebuild is, probably?, not
> useful, I don't see why we'd have a definition that errors out on
> explicit definition but not on an implicit reduction, as the package
> manager needs to be able to handle the situation anyways.

Why would it need to handle explicit empty groups? If all
use-conditionals inside a group evaluate to false, then it must be
able to compute it. That doesn't prevent us from having strict syntax
requirements.

IMHO it is unlikely that anyone would write an explicit || ( ) in an
ebuild. Then the only place where this can arise is a failed automatic
calculation of dependencies which presumably would be in an eclass.

A recent example is https://bugs.gentoo.org/620400 where the void ruby
dependency was discovered because Portage flagged the empty group.

> I'm all for banning the empty construct in QA scope though.

For my taste, we have too many of these already. If we decide that
explicit empty groups are useful (for what?), then we have no reason
to ban them by QA. If not, then why should the PM support them?
Furthermore, code that supports a banned construct will not see any
real life testing.

In addition, Portage doesn't support empty groups since 2011. That for
itself is not an argument to change PMS, but it shows that there is no
need for the construct.

Ulrich