-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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? Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFAEl+/ejvha5XGaMRAhlSAKCjL1CJ5TZT1c+K6qcDMUIVIPMSLACfQ7M2 Whd0XSwhfbvUFPRdjjRyOXs= =dRI7 -----END PGP SIGNATURE----- -- gentoo-portage-dev@gentoo.org mailing list
