1 |
In pre-EAPI-2, src_unpack phase was the most logical phase to be provided by |
2 |
SCM eclasses, thus classes has been set up to export ${ECLASS}_src_unpack. |
3 |
|
4 |
This phase in most (if not all) SCM eclasses provided: |
5 |
- unpack functionality - fetch and store in ${DISTDIR} |
6 |
- bootstrap functionality - either patching or bootstrapping just unpacked |
7 |
sourced with command |
8 |
|
9 |
In EAPI-2, bootstrap functionality belongs to prepare phase, thus it's been |
10 |
moved there - SCM eclasses in EAPI-2 codepath has been set up to provide |
11 |
src_prepare. |
12 |
|
13 |
And this is the problem (some people may be even unaware of it). |
14 |
In pre EAPI-2 it was sufficient to do the following in live ebuilds: |
15 |
|
16 |
inherit ${some_eclass} ${scm_eclass} |
17 |
|
18 |
${scm_eclass} inherited as last one, would just shadow src_unpack, providing |
19 |
what we want. In EAPI-2 however, it as well shadows src_prepare which is in |
20 |
*most* cases unwelcome, especially if one uses autopatcher (base.eclass, so |
21 |
cmake-utils.eclass, kde4-*.eclass, and probably some other). |
22 |
|
23 |
Because SCM bootstrap is either not used at all, or used very rarely, there's |
24 |
suggestion to: |
25 |
- either drop it |
26 |
- or (preferably) to make SCM eclasses export src_prepare only on specific |
27 |
request |
28 |
- or to make it easier - to not export it at all - thus making it required for |
29 |
developer to intentionally invoke ${ECLASS}_src_prepare if bootstrapping is |
30 |
required. |
31 |
|
32 |
-- |
33 |
regards |
34 |
MM |