1 |
On 05/07/12 11:17, Ulrich Mueller wrote: |
2 |
> |
3 |
> After all, this functionality is just a stop-gap measure for users to |
4 |
> apply quick bug fixes, so I don't expect that it will be used very |
5 |
> often. Even fewer cases will require that eautoreconf is called. Do we |
6 |
> really want to force developers to put this function call into every |
7 |
> ebuild? That would be out of proportion, IMHO. |
8 |
|
9 |
Only the ebuilds that override src_prepare (which is a lot). |
10 |
|
11 |
The argument on -dev was that we could get 80% of the benefit for 0% of |
12 |
the effort by just ignoring the issue. There's a trade-off, but 80% |
13 |
isn't all that great (considering of course that all of these numbers |
14 |
are made up). |
15 |
|
16 |
Can that be increased to, say, 99% without any extra effort? |
17 |
|
18 |
Are there easy heuristics to determine whether or not user patches |
19 |
require eautoreconf? For example, if the patches fail at the beginning |
20 |
of src_prepare, and the ebuild calls eautoreconf, that's a good |
21 |
indication that we should call eautoreconf after the user patches are |
22 |
applied (at the end of src_prepare). |
23 |
|
24 |
Lacking a better way, though, I think requiring the developer to apply |
25 |
the patches in the right spot is the only way to ensure correctness. |