Do not export PMS variables in EAPI 9

[Flowdalic]

Instead of passing PMS variables as part of the process environment, we pass them via a file that is later sourced by the ebuild's bash.

Since, for example, A is usually the greatest contributor to the process environment, removing it from the process environment significantly avoids running into MAX_ARG_STRLEN when spawning a new child process.

This means that A and other PMS variables are no longer exported in the ebuild and hence unavaiable to child processes. However, A is mostly used as part of the default_src_unpack function and there A does not need to be exported.

This started as a change that only unexported A, but was later extended to most PMS variables as suggested by ulm in https://bugs.gentoo.org/721088#c23.

Thanks to Zac Medico for helpful input on this change.

Closes: https://bugs.gentoo.org/721088

[zmedico]

We could probably make this just mysettings.get("EBUILD_PHASE") != "depend".

[Flowdalic]

I considered mysettings.get("EBUILD_PHASE") != "depend". The drawback is that, as soon as portage adds another phase with similar constraints like "depend", the code would need to be adjusted or otherwise the if-condition would erroneously hold. Whereas, if mysettings.get("EBUILD_PHASE") in _phase_func_map.keys() is true, then we know with the current implementation, that T will exists (since it is mandated for all PMS ebuild phase functions to exist) and this is also likely to be true for potential future PMS ebuild phase functions (simply because T is useful all the time).

That said, this was just explaining the rationale why I did it this way. I ultimately leave the decision to you, because you have far more experience with portage. Let me know if it should stay as it currently is, or if you want me to change it to mysettings.get("EBUILD_PHASE") != "depend".

[zmedico]

I think it's nicer to use mysettings.get("EBUILD_PHASE") != "depend" since we only implement the temp file cleanup for the depend phase. If we add another phase with similar constraints then it's easy enough to add a special case for it here.

[Flowdalic]

since we only implement the temp file cleanup for the depend phase.

Then we seem to have a general problem. I've added a debug print to emit the phase names we are seeing and got:

EBUILD_PHASE: clean
EBUILD_PHASE: cleanrm
EBUILD_PHASE: compile
EBUILD_PHASE: configure
EBUILD_PHASE: install
EBUILD_PHASE: instprep
EBUILD_PHASE: None
EBUILD_PHASE: package
EBUILD_PHASE: postinst
EBUILD_PHASE: postrm
EBUILD_PHASE: preinst
EBUILD_PHASE: prepare
EBUILD_PHASE: prerm
EBUILD_PHASE: setup
EBUILD_PHASE: test
EBUILD_PHASE: unpack

We don't even see a phase named "depend" there. Is that to be expeced?
From those phases, these are the ones that are neither "depend" or in _phase_func_map.keys():

clean
cleanrm
instprep
None
package

Note that we are also see an invocation where EBUILD_PHASE is None. Is that to be expected? I also see that the current approach leaves /tmp/portage-ebuild-extra-source-* files behind, created for the phases mentioned above (clean, cleanrm, instprep, None, package). Which would be in line with what we are seeing. I wonder if we shouldn't simply cleanup the file in the finally block at the end of the function, instead via EbuildMetadataPhase (That doesn't work in case returnpid or returnproc is active).

[Flowdalic]

A simple solution would be to only unexport the PMS variables if we are spawning in an EBUILD_PHASE in _phase_func_map.keys(), because then we can place the PORTAGE_EBUILD_EXTRA_SOURCE file inT. I've pushed this now.

The drawback would be, that the PMS variables are still exported when the ebuild is invoked without the intention to call a specific ebuild phase function. But it makes the implementation of the feature much cleaner, as we can bind the life cycle of the PORTAGE_EBUILD_EXTRA_SOURCE to T's life cycle.

If we also want to unexport the PMS vars in the clean, cleanrm, instprep, None, and package phases, then we need to come up with a good scheme to clean up the PORTAGE_EBUILD_EXTRA_SOURCE file at the end of those phases.

[zmedico]

You will only observe the depend phase when there is missing metadata cache for a particular ebuild. Once the cache is populated, you won't observe it again until there is an ebuild or eclass modification.

[zmedico]

If we also want to unexport the PMS vars in the clean, cleanrm, instprep, None, and package phases, then we need to come up with a good scheme to clean up the PORTAGE_EBUILD_EXTRA_SOURCE file at the end of those phases.

The problem is that we need to unexport them for all phases in order to prevent E2BIG errors.

[Flowdalic]

Now is a good time for others to test this patch and the feature. Set FEATURES="${FEATURES} -export-pms-vars" in make.conf to enable the behavior in all existing EAPIs. Make sure to use sys-apps/portage-9999, since sys-apps/portage was the only ebuild I have encountered so far that is affected by this change, and the -9999 ebuild of portage takes it into consideration.