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