| 1 |
On Sat, Jun 15, 2013 at 12:42 PM, Ciaran McCreesh |
| 2 |
<ciaran.mccreesh@××××××××××.com> wrote: |
| 3 |
> On Sat, 15 Jun 2013 18:24:13 +0200 |
| 4 |
> Tom Wijsman <TomWij@g.o> wrote: |
| 5 |
>> What does it take to change future specifications to guarantee this? |
| 6 |
> |
| 7 |
> You can have it from EAPI 6 onwards. |
| 8 |
> |
| 9 |
>> What's holding this from becoming guaranteed? Why not fix the specs? |
| 10 |
> |
| 11 |
> The specs accurately reflect Portage behaviour at the time the specs |
| 12 |
> were approved. The point of a stable EAPI is that once approved it |
| 13 |
> doesn't change. |
| 14 |
> |
| 15 |
|
| 16 |
From the council log, the main objection I saw was that we didn't want |
| 17 |
to change the behavior of existing ebuilds. |
| 18 |
|
| 19 |
In this particular case, we know that Portage has been properly |
| 20 |
handling die in a subshell since at least EAPI 4 was approved. |
| 21 |
|
| 22 |
I don't use Paludis, but we may have a similar situation there. |
| 23 |
|
| 24 |
If we find that all known implementations of PMS/EAPI 4 have |
| 25 |
implemented a certain behavior, making a change to that version of PMS |
| 26 |
to properly document the behavior seems reasonable. |
Archives