In pre-EAPI-2, src_unpack phase was the most logical phase to be provided by
SCM eclasses, thus classes has been set up to export ${ECLASS}_src_unpack.
This phase in most (if not all) SCM eclasses provided:
- unpack functionality - fetch and store in ${DISTDIR}
- bootstrap functionality - either patching or bootstrapping just unpacked
sourced with command
In EAPI-2, bootstrap functionality belongs to prepare phase, thus it's been
moved there - SCM eclasses in EAPI-2 codepath has been set up to provide
src_prepare.
And this is the problem (some people may be even unaware of it).
In pre EAPI-2 it was sufficient to do the following in live ebuilds:
inherit ${some_eclass} ${scm_eclass}
${scm_eclass} inherited as last one, would just shadow src_unpack, providing
what we want. In EAPI-2 however, it as well shadows src_prepare which is in
*most* cases unwelcome, especially if one uses autopatcher (base.eclass, so
cmake-utils.eclass, kde4-*.eclass, and probably some other).
Because SCM bootstrap is either not used at all, or used very rarely, there's
suggestion to:
- either drop it
- or (preferably) to make SCM eclasses export src_prepare only on specific
request
- or to make it easier - to not export it at all - thus making it required for
developer to intentionally invoke ${ECLASS}_src_prepare if bootstrapping is
required.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
