Right now, PMS describes what default phase functions are supposed to do, or even provides a code snippets for them. The same (or similar) bash code is repeated in various PMs, and possibly partially overriden or reused by eclasses. Maybe it's a good idea to provide default phase functions in an eclass or similar file, contained within the gx86 repo. PMs would inherit this eclass (say, default.eclass to match phase function names) implicitly and grab default phase functions there. The advantage of that solution would be reusing code and making it simpler to control its behavior (for example, right now Portage forces 'emake -j1' in src_test()). I guess some of the default EAPI functions could be moved to that eclass too.
So when you change src_test, you break every single package using the newer EAPI? Doesn't this idea defeat the entire point of having EAPIs?
(In reply to comment #1) > So when you change src_test, you break every single package using the newer > EAPI? Doesn't this idea defeat the entire point of having EAPIs? I meant having these implementations EAPI-specific, like eclasses currently do.
Then why not just have them as part of the package managers? The code reuse argument doesn't fly, since it's useful to be able to make use of package manager internal things to implement functions and helpers. And if you're sticking to EAPIs, you don't gain anything by making the changes in the tree as opposed to in the EAPI definition.
I withdraw this since people don't like it.
