1 |
18.08.2014 14:44, Rich Freeman пишет: |
2 |
> On Mon, Aug 18, 2014 at 4:54 AM, Sergey Popov <pinkbyte@g.o> wrote: |
3 |
>> 17.08.2014 01:54, William Hubbs пишет: |
4 |
>>> |
5 |
>>> # Foo and bar both have src_unpack and src_install functions. |
6 |
>>> # we want foo's src_unpack and bar's src_install: |
7 |
>>> |
8 |
>>> ECLASS_PHASES="foo_src_unpack |
9 |
>>> bar_src_install" |
10 |
>> |
11 |
>> You have my strong opposition on such change as well. It will turn |
12 |
>> ebuilds into unreadable and undpredictable mess, please do not do that |
13 |
>> |
14 |
> |
15 |
> I'm not sure I follow your complaint. He is talking about adding one |
16 |
> line to an ebuild. I'm not sure how that is unreadable, and the |
17 |
> algorithm you quoted looks fairly predictable to me as well. |
18 |
> |
19 |
> Certainly it is less convenient than not having to do anything to pull |
20 |
> in eclass-defined phase functions, and it requires ebuilds to be |
21 |
> updated when eclasses are updated to add new phase functions. That |
22 |
> could be problematic for cases like KDE/X11/etc where you have a large |
23 |
> collection of short ebuilds with all the logic in an eclass. |
24 |
> |
25 |
> I just want to make sure I'm understanding your concern in case there |
26 |
> is a new issue being raised. |
27 |
|
28 |
What's bad with overriding needed functions and saying which exported |
29 |
functions(from eclasses) to execute and in which order? |
30 |
|
31 |
Is this approach flaw? In which ways? |
32 |
|
33 |
-- |
34 |
Best regards, Sergey Popov |
35 |
Gentoo developer |
36 |
Gentoo Desktop Effects project lead |
37 |
Gentoo Proxy maintainers project lead |