On Fri, Feb 18, 2005 at 09:24:40PM -0500, Mike Frysinger wrote: > On Friday 18 February 2005 09:18 pm, Ciaran McCreesh wrote: > > No, but I might be demonstrating why epatch should be in its own eclass, > > and why eutils should be split up into several smaller eclasses with > > eutils being changed into a compatibility eclass which just inherits all > > these new smaller eclasses. One of the other intentions of the glep is to -avoid- having to do compatability crap like that. You're still ignoring -why- those functions should even be viewed by portage as potentially metadata modifying, additionaly the regen cost.
> Brian and i and others have talked in the past about the next logical step of > breaking portage up into sep packages ... one of which will be all the neat > little shell scripts like dolib/dobin/etc... Scripts such as dolib/dobin/etc are -ancillary- functions for ebuilds. They are used by the ebuild, but do not modify metadata/ebuild template. The precedent for elibs is already there, both in portage, and in eutils. So why the major dislike of it? If you don't like it, like anything in the tree, don't use it. Assuming the glep is greenlighted, the shift of portage ebuild support functionality into the tree will be via elibs, since that functionality doesn't modify metadata generation, further, that block of code's intentions differ from what eclasses address (modifying the template, and fooling with metadata). I guess I'm not really seeing how this is such an issue; it's a logical progression in the evolution of eclasses/our approach to handling the cache. The inherit eutils example was already pointed at- the addition of a depend. The solution you propose is a compatability hack, but it's not a complete solution as elibs/eclasses would allow. You can split eutils up into a 101 lil bits, but you change one of the sub-eclasses, and it forces a cache regen for all ebuilds/eclasses that inherit it, for no reason/gain. That functionality has _no_ intention of fooling with the template definition, nor the metadata. It's preferable that at the cache level (the level that matters for anything fetch/depend/rdepend), that file that holds said functionality *isn't even _able_* to modify the metadata/template. This is just defensive design, why give it the capability to do something the author didn't it to be able to do? That's what eclassess are for, and since they have that capability, they also are a different beast with different requirements (eclass cache verification fex). Eclasses and elibs are intended to address two different cases of code reusal, the intention of each is fundamentally different, as are the allowed/actual affects of each. So why lump apples and oranges together? What is the fault with elibs specifically, rather then pointing at eclasses and stating "well, we can half-ass do the equivalent now"... :) ~brian -- [email protected] mailing list
