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
