| 1 |
On Mon, Oct 2, 2017 at 4:05 PM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
> W dniu pon, 02.10.2017 o godzinie 22∶01 +0200, użytkownik Kristian |
| 3 |
> Fiskerstrand napisał: |
| 4 |
>> On 10/02/2017 09:58 PM, Rich Freeman wrote: |
| 5 |
>> > Does the PMS actually define what the correct behavior is for this |
| 6 |
>> > syntax? |
| 7 |
>> |
| 8 |
>> it evaluates to a true, i.e always valid/resolved. And although |
| 9 |
>> explicitly naming an empty group in an ebuild is, probably?, not useful, |
| 10 |
>> I don't see why we'd have a definition that errors out on explicit |
| 11 |
>> definition but not on an implicit reduction, as the package manager |
| 12 |
>> needs to be able to handle the situation anyways. I'm all for banning |
| 13 |
>> the empty construct in QA scope though. |
| 14 |
>> |
| 15 |
> |
| 16 |
> Have you read the commit message? The current spec makes no sense by |
| 17 |
> itself, and no package manager has been following it for 6+ years. |
| 18 |
> |
| 19 |
|
| 20 |
IMO the spec ought to define a correct behavior, which portage |
| 21 |
follows. Maybe that means changing the spec. Maybe that means |
| 22 |
changing portage. It sounds like the two don't match right now and |
| 23 |
that isn't really ideal, though it isn't necessarily a crisis at least |
| 24 |
in the explicit case which is degenerate. I imagine that if the |
| 25 |
implicit case were misbehaving we'd have heard of it by now, but I |
| 26 |
can't speak to what portage actually is doing and whether it follows |
| 27 |
the spec. |
| 28 |
|
| 29 |
And by all means ban explicit empty ()'s as a QA practice. |
| 30 |
|
| 31 |
|
| 32 |
-- |
| 33 |
Rich |
Archives