On Tue, Nov 29, 2016 at 6:24 PM, Mike Pagano <mpag...@gentoo.org> wrote:
> 2nd round. As per mgorny's advice, fix eapply_user as per PMS spec and
> execute in src_prepare. Support older EAPIs with epatch_user.
>
> ---
> eclass/kernel-2.eclass | 25 ++++++++++++++++++-------
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index 3f5fb3b..e516aff 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -95,7 +95,7 @@ has "${EAPI:-0}" 0 1 2 3 4 5 || die "kernel-2.eclass
> is unsupported for EAPI ${E
> PYTHON_COMPAT=( python{2_6,2_7} )
>
> inherit eutils toolchain-funcs versionator multilib python-any-r1
> -EXPORT_FUNCTIONS pkg_setup src_unpack src_compile src_test src_install
> pkg_preinst pkg_postinst pkg_postrm
> +EXPORT_FUNCTIONS pkg_setup src_prepare src_unpack src_compile src_test
> src_install pkg_preinst pkg_postinst pkg_postrm
I don't think calling "EXPORT_FUNCTIONS src_prepare" is legal in EAPI
0 or 1. You should probably move this behind an EAPI check.
Also, for EAPI, 2, 3, 4, and 5, this change might break existing
ebuilds; they may define src_prepare themselves, or inherit some other
eclass that also exports src_prepare.
Otherwise, this seems like a good next step.
