| 1 |
>>>>> On Wed, 30 Aug 2017, Kristian Fiskerstrand wrote: |
| 2 |
|
| 3 |
> On 08/29/2017 10:13 PM, Ulrich Mueller wrote: |
| 4 |
>> I request the Council to approve a PMS change, namely to ban empty |
| 5 |
>> dependency groups like "|| ( )" or "foo? ( )". |
| 6 |
>> |
| 7 |
>> Currently, any parenthesised groups in package dependency |
| 8 |
>> specifications [1] are permitted to contain zero items, and such empty |
| 9 |
>> groups evaluate to true. For logical disjuctions like "|| ( )" this |
| 10 |
>> deviates from the usual convention that empty operations should |
| 11 |
>> evaluate to false. |
| 12 |
|
| 13 |
> This might be a worthwhile change, but what measures needs to be taken |
| 14 |
> for maintainers etc when something is being masked as a result of this? |
| 15 |
> it seems it can result in a situation that the group becomes empty in |
| 16 |
> some remote part of the tree and causing a breakage, so any mask |
| 17 |
> potentially requires a full repoman run before committing? |
| 18 |
|
| 19 |
As I said previously, Portage flags empty groups as an error since |
| 20 |
2011 already. So it is extremely unlikely that anything in the Gentoo |
| 21 |
repository (or in any overlay) would still use that feature. |
| 22 |
|
| 23 |
> What are the downsides to the current logic? does it increase complexity |
| 24 |
> much in algorithms? |
| 25 |
|
| 26 |
First of all, literal "|| ( )" etc. are useless and I don't see why |
| 27 |
anyone would want to use them in an ebuild or eclass. (Even groups |
| 28 |
with *one* element are of very limited use, except for USE |
| 29 |
conditionals.) |
| 30 |
|
| 31 |
So the only place where this can occur is dependency strings |
| 32 |
automatically calculated in an eclass like "|| ( foo:1 foo:2 foo:3 )". |
| 33 |
If for some reason the group ends up to be empty, then the currently |
| 34 |
specified behaviour is quite surprising, because "|| ( )" will |
| 35 |
evaluate to true. You want it either to be false (as an empty logical |
| 36 |
disjunction) or to fail explicitly. |
| 37 |
|
| 38 |
See bug 620400 for a real-world example that occured recently: The |
| 39 |
ebuild claimed to have Ruby support, but all Ruby versions specified |
| 40 |
by it are gone. With empty groups being valid, that problem would not |
| 41 |
have been discovered, but would have lingered in the tree at least for |
| 42 |
some time. |
| 43 |
|
| 44 |
> What are reasons for introducing such changes retroactively instead of |
| 45 |
> specifying it in next EAPI version? |
| 46 |
|
| 47 |
For existing EAPIs, ebuilds cannot rely on the behaviour currently |
| 48 |
specified by PMS. Since also no ebuild in the tree uses the feature, |
| 49 |
tightening the spec seems to be the most straight forward path to me. |
| 50 |
|
| 51 |
Ulrich |
Archives