On 02:06 Fri 16 Sep , Brian Harring wrote: > 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.
So let me get this straight — instead, you want overlay users to maintain a copy of every eclass they use, which will almost automatically become outdated and stale because it won't track the gentoo-x86 version? > 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. I think Gentoo will always provide one or a set of "official" central repositories, that's pretty much the definition of a distribution. So yes, I'm saying that generally useful stuff could go into one of these repositories, which (in the multi-repo case) could be like the eclass metaphor for repos; others would depend on it implicitly or explicitly. > 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. I see EAPI as a nice thing for standardizing features that are implemented in the PM so they work identically across portage, pkgcore, and paludis. But I don't think that implementing things in the PM when they could go in an eclass is automatically the best choice. It dramatically slows down the speed of iteration, prototyping, and bug fixing. > 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). I think I explained above, but let me know if that's not the case. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com
pgpQi7rzibDrE.pgp
Description: PGP signature
