17.08.2014 01:54, William Hubbs пишет: > All, > > there is an ongoing discussion about how we handle eclass phase > functions by default [1]. > > Currently, EXPORT_FUNCTIONS is called in eclasses, and because of the > way this works, the phase function that is exported last in the chain of > inherited eclasses is the one that is called for a given phase, > overriding the PMS default phase function. > > The initial proposal is to change this behaviour so that the PMS default > phase functions call all matching phase functions from inherited > eclasses in sequence. > > For example: > > - your ebuild inherits foo and bar and each of them have src_unpack > functions. With this new behaviour, the default src_unpack would run > foo_src_unpack, bar_src_unpack, then perform its own actions. > > I strongly oppose this change, because I feel it will make our > entire tree very unpredictable at best. I realize this might eliminate > boilerplating from our tree. Weighing that against the possible > ramifications in this big of a change in automagic behaviour, I think > the cost is much higher than the gain. > > I am also not very comfortable with our current state, because it has > a lot of uncertainty in terms of how the eclass phase functions are > called. > > My counter proposal to this is that we stop calling eclass phase > functions automatically, and to minimize the amount of boilerplating > we would have to do, we use a variable, such as ECLASS_PHASES which > would be defined at the ebuild level and contain a list of the eclass > phase functions we want to run automatically. > > Going back to my previous example, say your ebuild does the following: > > -- code begins here -- > > inherit foo bar > > # 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" > > -- code ends here --- > > If ECLASS_PHASES is undefined, I think the default should be to not run > the eclass phase functions. > > Yes, this means there is some boilerplating. However, there are some > strong advantages: > > - this is no longer dependent on order of inheritance. > - The ebuild author knows exactly which eclass phase functions will > be run. > > Thoughts? > > William > > [1] https://bugs.gentoo.org/show_bugs.cgi?id=516014 >
You have my strong opposition on such change as well. It will turn ebuilds into unreadable and undpredictable mess, please do not do that -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Proxy maintainers project lead
signature.asc
Description: OpenPGP digital signature
