Zac Medico wrote: > 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.
That is a workaround, but it makes a pretty hard link between the package manager and the functions, which is exactly what I am trying to cut through with the patch. Sure, it'd be a workaround, but just keeping them in the portage package until EAPI=1 is reached is one too... >>> 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? It wouldn't be implied anymore. The install-helpers.eclass would actually be like every other eclass, like eutils fex. Actually, the reason they won't like it for will more likely be that it requires adding another eclass to the inherit line for ~15'000 ebuilds. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-portage-dev@gentoo.org mailing list
