> 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
>>>> 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
As I've mentioned in bug #380391 , 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.