| 1 |
>>>>> On Mon, 2 Oct 2017, Kristian Fiskerstrand wrote: |
| 2 |
|
| 3 |
> On 10/02/2017 09:58 PM, Rich Freeman wrote: |
| 4 |
>> Does the PMS actually define what the correct behavior is for this |
| 5 |
>> syntax? |
| 6 |
|
| 7 |
> it evaluates to a true, i.e always valid/resolved. And although |
| 8 |
> explicitly naming an empty group in an ebuild is, probably?, not |
| 9 |
> useful, I don't see why we'd have a definition that errors out on |
| 10 |
> explicit definition but not on an implicit reduction, as the package |
| 11 |
> manager needs to be able to handle the situation anyways. |
| 12 |
|
| 13 |
Why would it need to handle explicit empty groups? If all |
| 14 |
use-conditionals inside a group evaluate to false, then it must be |
| 15 |
able to compute it. That doesn't prevent us from having strict syntax |
| 16 |
requirements. |
| 17 |
|
| 18 |
IMHO it is unlikely that anyone would write an explicit || ( ) in an |
| 19 |
ebuild. Then the only place where this can arise is a failed automatic |
| 20 |
calculation of dependencies which presumably would be in an eclass. |
| 21 |
|
| 22 |
A recent example is https://bugs.gentoo.org/620400 where the void ruby |
| 23 |
dependency was discovered because Portage flagged the empty group. |
| 24 |
|
| 25 |
> I'm all for banning the empty construct in QA scope though. |
| 26 |
|
| 27 |
For my taste, we have too many of these already. If we decide that |
| 28 |
explicit empty groups are useful (for what?), then we have no reason |
| 29 |
to ban them by QA. If not, then why should the PM support them? |
| 30 |
Furthermore, code that supports a banned construct will not see any |
| 31 |
real life testing. |
| 32 |
|
| 33 |
In addition, Portage doesn't support empty groups since 2011. That for |
| 34 |
itself is not an argument to change PMS, but it shows that there is no |
| 35 |
need for the construct. |
| 36 |
|
| 37 |
Ulrich |
Archives