1 |
>>>>> On Mon, 7 May 2012, Micha³ Górny wrote: |
2 |
|
3 |
> On Mon, 07 May 2012 12:19:40 -0400 |
4 |
> Michael Orlitzky <michael@××××××××.com> wrote: |
5 |
|
6 |
>> > After all, this functionality is just a stop-gap measure for users |
7 |
>> > to apply quick bug fixes, so I don't expect that it will be used |
8 |
>> > very often. Even fewer cases will require that eautoreconf is |
9 |
>> > called. Do we really want to force developers to put this function |
10 |
>> > call into every ebuild? That would be out of proportion, IMHO. |
11 |
>> |
12 |
>> Only the ebuilds that override src_prepare (which is a lot). |
13 |
|
14 |
> The reason for src_prepare() was to simplify ebuilds (so they don't |
15 |
> have to override whole src_unpack()). Requiring a specific line in |
16 |
> every src_prepare() call means going the other way. |
17 |
|
18 |
+1 |
19 |
|
20 |
Also, if we add the feature to EAPI 5, we won't get anything close to |
21 |
100% coverage for a very long time. (Looking at usage statistics, EAPI |
22 |
2 was introduced almost 4 years ago, and about 30% of the tree are |
23 |
still at EAPI 0 or 1.) |
24 |
|
25 |
Couldn't the PM call a user-supplied script (which would be a file |
26 |
with a special name placed in the same directory) after applying the |
27 |
user patches? Since this script could do any postprocessing required, |
28 |
applying user patches could be postponed until after src_prepare. |
29 |
|
30 |
Ulrich |