Brian Harring wrote: > Make this change, and it means that all overlays that can function as > standalone, must bundle the eapi helpers themselves.
Not true. I don't have to add eutils.eclass to my overlay to use epatch. Same goes for install-helpers.eclass. Standalone-repos will have that problem, but there is none yet to my knowledge. Sure, the problem persists for future repos, but it's not so much of a deal to copy an eclass once. Also, as it stands today, portage IS connected to gentoo-x86 through exactly these helpers. Upon the needs of the portage tree the functions in portage are changed, and this is simply not correct. > This is ignoring the potential fun of an overlay that redefines an > eapi locked function. eclasses in overlays that also exist in the tree are fun anyway. If people are messing with eutils, we tell them that it is entirely their responsibility if something breaks. Same goes for install-helpers.eclass. That being said, this problem already exists today: A custom eclass could simply define a function 'dosbin' and ebuild.sh would use that one. While it's a possible cause for breakage, it's not an argument against the move. > A) requirement of trying to keep helper functionality exactly in sync > per tree, If the helpers were a part of the EAPI those trees would have to verify that the EAPI portage provides matches their needs. Whether you sync against portage or the portage tree is not a big difference. > B) fragmentation this implicitly enables > isn't good. I agree here. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-portage-dev@gentoo.org mailing list
