| 1 |
>>>>> On Wed, 20 Jun 2012, Ciaran McCreesh wrote: |
| 2 |
|
| 3 |
> On Wed, 20 Jun 2012 17:44:36 +0200 |
| 4 |
> Ulrich Mueller <ulm@g.o> wrote: |
| 5 |
>> I disagree with this. As it is currently worded, every ebuild would |
| 6 |
>> be required to call a special function in src_prepare. This is the |
| 7 |
>> worst possible solution, IMHO. |
| 8 |
|
| 9 |
> Every ebuild that defines its own src_prepare, yes. That's the |
| 10 |
> point: the package mangler can't know where to apply patches itself |
| 11 |
> otherwise, and user patches are rare enough that developers are very |
| 12 |
> likely to forget to check if they aren't made to. |
| 13 |
|
| 14 |
Right, user patches are rare, and patches that change the build system |
| 15 |
such that eautoreconf is necessary are even rarer. |
| 16 |
|
| 17 |
I'd say that EAPI 5 should provide an "apply_patches_here" function |
| 18 |
that can be called by ebuilds, but if the ebuild hasn't called the |
| 19 |
function, then it should fall back to applying user patches just after |
| 20 |
src_prepare. |
| 21 |
|
| 22 |
> We had this discussion in the original thread. If we're just looking |
| 23 |
> for a feature that "might work sometimes", there's no point sticking |
| 24 |
> any of this in the EAPI at all. |
| 25 |
|
| 26 |
I don't see why the above wouldn't work. The user still has complete |
| 27 |
control, because he can always patch (e.g.) configure along with |
| 28 |
configure.in. |
| 29 |
|
| 30 |
Then there are ebuilds that don't call eautoreconf, in the first |
| 31 |
place. Should we require that all of them inherit autotools now, just |
| 32 |
for the unlikely case that user patches could be applied? |
| 33 |
|
| 34 |
Ulrich |
Archives