1 |
On 04/27/2012 11:57 AM, Michał Górny wrote: |
2 |
> On Fri, 27 Apr 2012 20:01:15 +0200 |
3 |
> Ulrich Mueller <ulm@g.o> wrote: |
4 |
> |
5 |
>>>>>>> On Fri, 27 Apr 2012, Zac Medico wrote: |
6 |
>> |
7 |
>>> Since we've managed to survive up to this point without such a |
8 |
>>> feature, I think it's worth the wait roll it into EAPI 5 and have a |
9 |
>>> clean solution that doesn't rely on package manager interaction with |
10 |
>>> eclasses. If we quickly draft an EAPI 5 spec, there's still have |
11 |
>>> time to have it approved at the next council meeting. |
12 |
>> |
13 |
>> Did I get it right, you are thinking about a special EAPI only for |
14 |
>> user patches? I'd say that the feature is not important enough to |
15 |
>> justify that. |
16 |
> |
17 |
> +1. Either we use EAPIs with some thinking or just drop that concept |
18 |
> and move on to something else. |
19 |
> |
20 |
> There is a number of features waiting for new EAPI, and noone yet even |
21 |
> considered them. But when it comes to marginal feature which many of |
22 |
> devs don't even accept, it's enough to quickly release a new EAPI which |
23 |
> most of the tree won't support. |
24 |
|
25 |
The fact that it's a "marginal feature" is exactly why I don't think it |
26 |
justifies adding a quick and dirty hack that introduces an interaction |
27 |
between the package manager an eclass function like epatch_user. |
28 |
|
29 |
On the other hand, if it's important enough to justify a quick and dirty |
30 |
hack in the package manager, then I'd argue that it's also important |
31 |
enough to justify a quick and clean EAPI bump. |
32 |
-- |
33 |
Thanks, |
34 |
Zac |