>>>>> On Sun, 8 Apr 2018, Marty E Plummer wrote:

> Split all functions unique to eutils into eutils-r1, and inherit it
> from eutils. Issue a QA warning on EAPI=6 ebuilds using eutils directly
> and suggest migrating to direct use of the needed eclass, with a list of
> functions unique to eutils-r1.

> With this we can start moving ebuilds which inherit eutils because they
> need a function unique to the old eutils to eutils-r1, while being able
> to single out ebuilds which used eutils to inherit other ebuilds lazily
> or just cargo cult coding of always inheriting eutils.

I fear that at this point, shortly before approval of EAPI 7, this
doesn't make much sense. More than half of the tree is at EAPI 6, so
that QA warning would be shown for many ebuilds.

Also in EAPI 7 some functions won't be in eutils any more. For example,
eqawarn will be provided by the package manager. So that -r1 eclass
would start out with ugly EAPI conditionals.

So, IMHO the cleaner procedure is to wait with this for EAPI 7, where
we may be able to do the migration without a revision bump of the
eclass.

Ulrich