On 09/16/2011 02:06 AM, Brian Harring wrote: > On Thu, Sep 15, 2011 at 10:00:19PM -0500, Donnie Berkholz wrote: >> On 17:29 Wed 14 Sep , Brian Harring wrote: >>> On Wed, Sep 14, 2011 at 02:16:41PM -0500, Donnie Berkholz wrote: >>>> On 19:14 Tue 13 Sep , Brian Harring wrote: >>>>> On Tue, Sep 13, 2011 at 09:02:28PM -0500, Donnie Berkholz wrote: >>>>>> On 17:56 Tue 13 Sep , Mike Frysinger wrote: >>>>>>> useful enough for EAPI ? or should i just stick it into eutils.eclass >>>>>>> ? OR BOTH !? >>>>>> >>>>>> I prefer to avoid EAPI whenever possible, as it just makes things slower >>>>>> and more complex. >>>>> >>>>> Exactly the wrong approach; it winds up with master >>>>> repositories/overlays cloning the functionality all over the damn >>>>> place. >>>> >>>> Why are people cloning anything if it's in eutils.eclass in gentoo-x86? >>> >>> There are more repositories than just gentoo-x86, and overlay is *not* >>> the only configuration in use. >> >> Who else besides you is using any other configuration? Should we really >> give a crap about the 0.001% population with some weird setup when we're >> trying to improve things for the 99.999% one? > > Specious argument; the point of controllable stacking was to avoid the > issue of overlay's forcing their eclasses upon gentoo-x86 ebuilds > (which may not support those modified eclasses) via the old > PORTDIR_OVERLAY behaviour. This is why multiple repositories have > layout.conf master definitions- to explicitly mark that they > require/consume a seperate repo. > > What you're basically proposing is a variation of the "push format > definitions into a central tree, and require everyone to use that > central tree". This discussion has come and gone; I say that being > one of the folks who was *pushing for the repository solution*. The > problem there is it fundamentally enables (more forces) fragmentation. > > Realistically I assume you're taking the stance "EAPI gets in the way, > lets do away with it"- if so, well, out with it, and I'll dredge up > the old logs/complaints that lead to EAPI. > > >>> In the old days of the PM only handling a single overlay stack, what >>> you're suggesting would be less heinous- heinous in detail, but >>> pragmatic in reality. These days it's a regressive approach- >>> requiring everyone to slave gentoo-x86 isn't sane, nor is avoiding >>> eapi (resulting in people having to duplicate code into each >>> repository stack). >> >> I don't know many people who aren't using gentoo-x86 or a repo that >> pulls in changes directly from it. > > rephrase please; either you're saying "everyone uses gentoo-x86" which > is sort of true (funtoo/chrome aren't necessarily riding HEAD/trunk > however which means things can get ugly for derivative repository > usage), but still ignores the situations where people have overlays > w/ developmental eclasses that they need to selectively control where > it overrides (which is where the notion of repo stacking comes into > play). > ~brian
As I've mentioned in bug #380391 [1], a possible hybrid approach would be to distribute an eclass library that can be installed as a dependency of the package manager. This would provide benefits similar to those of using eclasses from gentoo-x86, while avoiding the introduction of a dependencies on either gentoo-x86 or package manager implementations. [1] https://bugs.gentoo.org/show_bug.cgi?id=380391#c3 -- Thanks, Zac
