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