-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simon Stelling wrote: > 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...
It's not intended as a workaround and it shouldn't create a hard link between the package manager and the functions. The idea is that the tree should provide the necessary information for the package manager (portage or not) to determine how it should setup the environment for a given EAPI. The file containing the functions from install-helpers.eclass would have to be labeled in some way such that any package manager would know that those functions are required when EAPI=0 (and possible other EAPI levels). >>>> 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. Fine, but the EAPI can still be used to imply that some other functions may or may not be available. > 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. See, that statement shows me that you've missed my point that EAPI can be used to imply which functions are implicitly available. It would be redundant to inherit an eclass containing functions that are already implied by the EAPI. Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFAFVc/ejvha5XGaMRAoKBAKDPB+W/e1BVL11NJYWX3NlRdizJUwCfYI4l dPKQMsEBZbs8qkBQBTeUVJU= =1IQL -----END PGP SIGNATURE----- -- gentoo-portage-dev@gentoo.org mailing list
