1 |
>>>>> On Sun, 8 Apr 2018, Marty E Plummer wrote: |
2 |
|
3 |
> Split all functions unique to eutils into eutils-r1, and inherit it |
4 |
> from eutils. Issue a QA warning on EAPI=6 ebuilds using eutils directly |
5 |
> and suggest migrating to direct use of the needed eclass, with a list of |
6 |
> functions unique to eutils-r1. |
7 |
|
8 |
> With this we can start moving ebuilds which inherit eutils because they |
9 |
> need a function unique to the old eutils to eutils-r1, while being able |
10 |
> to single out ebuilds which used eutils to inherit other ebuilds lazily |
11 |
> or just cargo cult coding of always inheriting eutils. |
12 |
|
13 |
I fear that at this point, shortly before approval of EAPI 7, this |
14 |
doesn't make much sense. More than half of the tree is at EAPI 6, so |
15 |
that QA warning would be shown for many ebuilds. |
16 |
|
17 |
Also in EAPI 7 some functions won't be in eutils any more. For example, |
18 |
eqawarn will be provided by the package manager. So that -r1 eclass |
19 |
would start out with ugly EAPI conditionals. |
20 |
|
21 |
So, IMHO the cleaner procedure is to wait with this for EAPI 7, where |
22 |
we may be able to do the migration without a revision bump of the |
23 |
eclass. |
24 |
|
25 |
Ulrich |