Considering that every build system out there expect for autotools requires either inheriting a specific eclass or redefining phase functions, and we already have an eclass for autotools as well (which some devs use, and some devs refuse to because 'it's redundant'), why don't we remove all default phase functions in a future EAPI and just require ebuilds to explicitly inherit build system-specific eclass? As I see it, this has the following advantages: - all build systems are treated equally and explicitly -- we gain consistency, - all changes to the autotools build procedure can be done on the eclass update procedure rather than modifying PMS and requiring new EAPIs for no good reason, - the discussion whether to use text descriptions or code snippets for default phase functions is over, - PM no longer has to internally reuse the license used by default phase function snippets (I think Brian mentioned something about that), - PM no longer has to copy the same default code and is no longer able to hack them in a manner incompatible with other PMs.
Down this path lies people making "obvious" and "trivial" changes that "won't break anything" to the defaults...
(In reply to comment #1) > Down this path lies people making "obvious" and "trivial" changes that "won't > break anything" to the defaults... Right now they can as well. Going down your path, we end up with single person-distro, just because others can break it. And yes, I'm aware that there are some devs who don't care about anyone and just do what they want to. We should start handling that rather than trying to move everything out of their reach.
We might also want to consider various hybrid approaches: A) Package manager provides some default eclasses B) Package manager depends on a package which installs some default eclasses (and this default eclass distribution can be shared by multiple package managers) By separating the eclasses from the repository in this way, it eliminates a dependency on the 'gentoo' repository.
there's fundamentally two different ideas ... making the default a nop, and moving the defaults to the tree. on the default->nop part, i dont think that makes sense. if the majority of packages are configure/make based, then it only makes sense for those to be the default. and considering it's trivial to write your own eclass with your own defaults, i dont see this being a hindrance whatsoever. so, as for "all build systems are treated equally and explicitly", that's just fluff. the focus is on making the default simple/easy, not on treating everyone equally.
I'm no longer for this, and we're kinda going the opposite direction.
