| 1 |
On 02:06 Fri 16 Sep , Brian Harring wrote: |
| 2 |
> Specious argument; the point of controllable stacking was to avoid the |
| 3 |
> issue of overlay's forcing their eclasses upon gentoo-x86 ebuilds |
| 4 |
> (which may not support those modified eclasses) via the old |
| 5 |
> PORTDIR_OVERLAY behaviour. This is why multiple repositories have |
| 6 |
> layout.conf master definitions- to explicitly mark that they |
| 7 |
> require/consume a seperate repo. |
| 8 |
|
| 9 |
So let me get this straight — instead, you want overlay users to |
| 10 |
maintain a copy of every eclass they use, which will almost |
| 11 |
automatically become outdated and stale because it won't track the |
| 12 |
gentoo-x86 version? |
| 13 |
|
| 14 |
> What you're basically proposing is a variation of the "push format |
| 15 |
> definitions into a central tree, and require everyone to use that |
| 16 |
> central tree". This discussion has come and gone; I say that being |
| 17 |
> one of the folks who was *pushing for the repository solution*. The |
| 18 |
> problem there is it fundamentally enables (more forces) fragmentation. |
| 19 |
|
| 20 |
I think Gentoo will always provide one or a set of "official" central |
| 21 |
repositories, that's pretty much the definition of a distribution. So |
| 22 |
yes, I'm saying that generally useful stuff could go into one of these |
| 23 |
repositories, which (in the multi-repo case) could be like the eclass |
| 24 |
metaphor for repos; others would depend on it implicitly or explicitly. |
| 25 |
|
| 26 |
> Realistically I assume you're taking the stance "EAPI gets in the way, |
| 27 |
> lets do away with it"- if so, well, out with it, and I'll dredge up |
| 28 |
> the old logs/complaints that lead to EAPI. |
| 29 |
|
| 30 |
I see EAPI as a nice thing for standardizing features that are |
| 31 |
implemented in the PM so they work identically across portage, pkgcore, |
| 32 |
and paludis. But I don't think that implementing things in the PM when |
| 33 |
they could go in an eclass is automatically the best choice. It |
| 34 |
dramatically slows down the speed of iteration, prototyping, and bug |
| 35 |
fixing. |
| 36 |
|
| 37 |
> rephrase please; either you're saying "everyone uses gentoo-x86" which |
| 38 |
> is sort of true (funtoo/chrome aren't necessarily riding HEAD/trunk |
| 39 |
> however which means things can get ugly for derivative repository |
| 40 |
> usage), but still ignores the situations where people have overlays w/ |
| 41 |
> developmental eclasses that they need to selectively control where it |
| 42 |
> overrides (which is where the notion of repo stacking comes into |
| 43 |
> play). |
| 44 |
|
| 45 |
I think I explained above, but let me know if that's not the case. |
| 46 |
|
| 47 |
-- |
| 48 |
Thanks, |
| 49 |
Donnie |
| 50 |
|
| 51 |
Donnie Berkholz |
| 52 |
Council Member / Sr. Developer |
| 53 |
Gentoo Linux |
| 54 |
Blog: http://dberkholz.com |
Archives