On Thu, Sep 07, 2006 at 09:32:04AM -0700, Zac Medico wrote: > Simon Stelling wrote: > > repo-level profile, we move parts of the EAPI out into the tree, which > > is a bad idea because we are unable to support multiple versions. As the > > EAPI needed for the ebuild is unknown when sourcing > > install-helpers.eclass, we're actually forced into using that one and > > only version, which is quite limiting. > > Well, if the metadata generation step is viewed as being separate from the > rest, > and the helpers aren't needed during that step, then it's possible to get the > EAPI from the ebuild without the helpers being in the environment. Once the > EAPI is known, the package manager can use that to determine what else (if > anthing) needs to be added to the environment. Then you'd only need a way to > tell the package manager which EAPI levels the functions in your > install-helpers.eclass (or whatever) apply to. > > > So, the correct way to do it is to define an EAPI=1 that does no longer > > include these helper functions and make the eclasses/ebuilds that use it > > inherit the eclass manually. However, this will need to run through -dev > > and I'm afraid the ebuild devs wouldn't like it at all :-/ > > They won't like it because it's expected that EAPI will provide the necessary > information. Why should they have to inherit some special eclass if it's > already implied by the EAPI that they've specified?
Blubb left out the real kicker. Make this change, and it means that all overlays that can function as standalone, must bundle the eapi helpers themselves. This is ignoring the potential fun of an overlay that redefines an eapi locked function. Understand initial intention of wanting to make the scripts usable by all pkg managers (pushed this myself shortly after I became a portage dev), but the A) requirement of trying to keep helper functionality exactly in sync per tree, B) fragmentation this implicitly enables isn't good. ~harring
pgpnCDHRvNPUM.pgp
Description: PGP signature
