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
> 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
> 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
I think I explained above, but let me know if that's not the case.
Council Member / Sr. Developer