| 1 |
On Sat, Mar 21, 2009 at 10:37 AM, Patrick Lauer <patrick@g.o> wrote: |
| 2 |
> Hi all, |
| 3 |
> |
| 4 |
> with the discussion about EAPI3 we have now 4 (or 7, depending on how you |
| 5 |
> count them ;) ) EAPIs available or almost available. This is getting quite |
| 6 |
> confusing. |
| 7 |
|
| 8 |
Be more specific, what actual problems have you encountered? |
| 9 |
What are some other ways we could mitigate these issues (it seems like |
| 10 |
tool improvements could be a big one here)? |
| 11 |
|
| 12 |
> To make our lives easier I would suggest deprecating EAPI0 and migrating |
| 13 |
> existing ebuilds over some time to EAPI1 or higher until EAPI0 can be |
| 14 |
> obsoleted at some point in the future. |
| 15 |
> I would set the start of deprecation warnings about 3 months from now and the |
| 16 |
> obsoletion quite a time later, maybe 12 months from now, when a sufficient |
| 17 |
> amount of ebuilds has been migrated. |
| 18 |
|
| 19 |
I am interested in the number of ebuilds at specific APIs in the tree, |
| 20 |
do you have those numbers? |
| 21 |
Basically, how much work is this (raw ebuild count)? |
| 22 |
|
| 23 |
> |
| 24 |
> Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to |
| 25 |
> think about, but since it has some changes like adding src_prepare migration |
| 26 |
> would not be as trivial. So I'd prefer keeping it around a bit longer. |
| 27 |
> |
| 28 |
> Comments? |
| 29 |
> |
| 30 |
> |
| 31 |
> Patrick |
| 32 |
> |
| 33 |
> |
Archives