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