1 |
On Wed, 20 Jun 2012 18:45:31 +0200 |
2 |
Ulrich Mueller <ulm@g.o> wrote: |
3 |
> I'd say that EAPI 5 should provide an "apply_patches_here" function |
4 |
> that can be called by ebuilds, but if the ebuild hasn't called the |
5 |
> function, then it should fall back to applying user patches just after |
6 |
> src_prepare. |
7 |
|
8 |
But applying user patches after src_prepare is wrong. We already had |
9 |
this discussion. |
10 |
|
11 |
> > We had this discussion in the original thread. If we're just looking |
12 |
> > for a feature that "might work sometimes", there's no point sticking |
13 |
> > any of this in the EAPI at all. |
14 |
> |
15 |
> I don't see why the above wouldn't work. The user still has complete |
16 |
> control, because he can always patch (e.g.) configure along with |
17 |
> configure.in. |
18 |
|
19 |
Not really, since patches mess with timestamps. |
20 |
|
21 |
> Then there are ebuilds that don't call eautoreconf, in the first |
22 |
> place. Should we require that all of them inherit autotools now, just |
23 |
> for the unlikely case that user patches could be applied? |
24 |
|
25 |
If the aim is to provide a working feature to users, yes. The |
26 |
alternative is to not provide user patches support. |
27 |
|
28 |
-- |
29 |
Ciaran McCreesh |