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.