On Sun, 18 Oct 2015 19:36:09 +0100 Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> On Sun, 18 Oct 2015 20:19:12 +0200 > Alexis Ballier <aball...@gentoo.org> wrote: > > what I was trying to understand is what is the usefulness of eapply > > vs epatch > > The point of eapply is that it's inside the package manager, so it can > safely be used by default phase functions, for user patches, etc. For user patches, I agree, but it can be very loosely defined and left implementation dependent instead of mandated by PMS. For default phases, see below. > Rather than it being a direct copy of the epatch API, we took this as > an opportunity to tidy up the behaviour to make it do something easy > to understand and sensible, rather than being full of scary voodoo > heuristics which are rarely necessary (and when they are, fixing your > patches is easy) and which have weird effects that you don't know > about until it's too late. Makes sense, but it equally applies to 'patch', or worse: I've seen many patches working with some 'patch' version and being rejected by other versions. I've never seen anything like that caused by epatch itself. > Of course, this is part of the larger debate on "as much as possible > in the PM" versus "as much as possible in the tree". The main "in the > PM" argument is "less breakage and better testing"; the main "in the > tree" argument is that things going spectacularly wrong for users > every now and again is fine because it lets developers have new > useless toys slightly faster. (This is a totally unbiased and > entirely comprehensive summary of the debate.) clearly unbiased :) The main "in the PM" argument is "everything must be discussed until it is perfect, and if it happens not to be later on then start again the process and it'll be fixed next year"; the main "in the tree" argument is about admitting that no code is perfect nor can do everything we need from its inception but can be fixed and improved easily. There are things that must be properly specified, for which PMS does a very good job at, but others that are just implementation details which IMHO have nothing to do with a spec: default phases could very well be defined by an implicit 'inherit default-phase-functions' applying to all ebuilds and be done with the specification, interoperability problems, etc. You'd tell me we then would have no guarantee that changing something in that eclass wouldn't break an obscure ebuild, which is true, but heh, isn't it the whole point of eclasses ? :) (or rather, this eclass can have very strict pre-commit review & testing rules) [...]
