Re: [gentoo-dev] [PATCH 1/1] Fix eapply_user as per PMS spec and execute in, src_prepare. Support older EAPIs with epatch_user.
On 11/29/2016 07:05 PM, Mike Gilbert wrote: > On Tue, Nov 29, 2016 at 6:24 PM, Mike Paganowrote: >> 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. > Thank-you, I did see that in another eclass. (EXPORT) I will revise and resend tomorrow. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/1] Fix eapply_user as per PMS spec and execute in, src_prepare. Support older EAPIs with epatch_user.
On Tue, Nov 29, 2016 at 6:24 PM, Mike Paganowrote: > 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.