| 1 |
On 06/15/13 19:02, Mike Gilbert wrote: |
| 2 |
> On Sat, Jun 15, 2013 at 1:01 PM, Ciaran McCreesh |
| 3 |
> <ciaran.mccreesh@××××××××××.com> wrote: |
| 4 |
>> On Sat, 15 Jun 2013 12:56:00 -0400 |
| 5 |
>> Mike Gilbert <floppym@g.o> wrote: |
| 6 |
>>> If we find that all known implementations of PMS/EAPI 4 have |
| 7 |
>>> implemented a certain behavior, making a change to that version of PMS |
| 8 |
>>> to properly document the behavior seems reasonable. |
| 9 |
>> Part of the point of EAPI stability is that it doesn't just apply to |
| 10 |
>> current versions of package manglers. |
| 11 |
>> |
| 12 |
> So look back at the first versions which implemented EAPI 4 support, |
| 13 |
> and see what the behavior was implemented at the point in time. |
| 14 |
> |
| 15 |
it make sense but it stretch things a lot. |
| 16 |
|
| 17 |
Is it possible to: |
| 18 |
- keep an open bug (tracker) on named eclasses/ebuilds, so we (users and |
| 19 |
devs) know that there is a (teoric) fallacy |
| 20 |
- approve it for EAPI 6 |
| 21 |
- move all the eapi/ebuilds to EAPI 6 |
| 22 |
- close the bugs as WONT-FIX |
| 23 |
|
| 24 |
In any case it should be easy to port an ebuild from EAPI4 to 6, if |
| 25 |
gentoers want to keep things simple it could be more a version 5a than 6 |
| 26 |
|
| 27 |
regards |
Archives