On Mon, Aug 18, 2014 at 8:21 AM, Sergey Popov <pinkb...@gentoo.org> wrote: > 18.08.2014 14:44, Rich Freeman пишет: >> On Mon, Aug 18, 2014 at 4:54 AM, Sergey Popov <pinkb...@gentoo.org> wrote: >>> 17.08.2014 01:54, William Hubbs пишет: >>>> >>>> # Foo and bar both have src_unpack and src_install functions. >>>> # we want foo's src_unpack and bar's src_install: >>>> >>>> ECLASS_PHASES="foo_src_unpack >>>> bar_src_install" >>> >>> You have my strong opposition on such change as well. It will turn >>> ebuilds into unreadable and undpredictable mess, please do not do that >>> >> >> I'm not sure I follow your complaint. He is talking about adding one >> line to an ebuild. I'm not sure how that is unreadable, and the >> algorithm you quoted looks fairly predictable to me as well. >> >> Certainly it is less convenient than not having to do anything to pull >> in eclass-defined phase functions, and it requires ebuilds to be >> updated when eclasses are updated to add new phase functions. That >> could be problematic for cases like KDE/X11/etc where you have a large >> collection of short ebuilds with all the logic in an eclass. >> >> I just want to make sure I'm understanding your concern in case there >> is a new issue being raised. > > What's bad with overriding needed functions and saying which exported > functions(from eclasses) to execute and in which order? > > Is this approach flaw? In which ways?
Ok, I was misunderstanding your original comment. You're advocating just having ebuilds explicitly call phase functions from eclasses then, and not automatically inheriting them? Your objection was to the ECLASS_PHASES concept, and not to the principle of eliminating automatic inheritance of phase functions? Please let me know if I'm still misunderstanding you. There are a lot of potential ways to go with this so it isn't always clear what part of a proposal is being objected to. Rich
