Bitbake 2.0 refuses to run in pyrex; inclusive language violations

[amstewart]

When running any bitbake version >= 2.0 within a pyrex container, bitbake will throw a fatal error during recipe parsing and return code 1.

[0] usr0:build$ bitbake -e glibc
ERROR: Variable BB_ENV_EXTRAWHITE has been renamed to BB_ENV_PASSTHROUGH_ADDITIONS
ERROR: Variable BB_ENV_EXTRAWHITE from the shell environment has been renamed to BB_ENV_PASSTHROUGH_ADDITIONS
ERROR: Exiting to allow enviroment variables to be corrected

The error source is here, and it was added to enforce restrictions on insufficiently inclusive variables being defined in the environment. Bitbake will error whenever BB_ENV_EXTRAWHITE is defined in the execution environment, and it is unconditionally defined by pyrex.

pyrex/pyrex.py

Lines 554 to 557 in bebe3f9

	# Pass along BB_ENV_EXTRAWHITE and anything it has whitelisted
	if "BB_ENV_EXTRAWHITE" in os.environ:
	engine_args.extend(["-e", "BB_ENV_EXTRAWHITE"])
	container_envvars.extend(os.environ["BB_ENV_EXTRAWHITE"].split())

pyrex/image/capture.sh

Lines 100 to 103 in bebe3f9

	"export": {
	"BB_ENV_EXTRAWHITE": "$BB_ENV_EXTRAWHITE",
	"BUILDDIR": "$BUILDDIR"
	}

Bitbake 2.0 support is needed for pyrex users to build the OE kirkstone release and beyond.

[amstewart]

At the highest level, I think we have a few options to approach this issue. From most-desirable to least-...

1. Have pyrex use whichever version of the whitelist variable name is defined in the container host environment.
   • This would enable users to control which version of bitbake they support via their container environment configuration - which is very pyrexy. It also enables them to quickly react to accidently using the wrong variable, since they can just undefine and redefine it from their host.
   • However, since capture.sh is built into the pyrex image, we may have to slightly rearchitect the image. (I'm not sure about this.)
2. Find-replace all instances of BB_ENV_EXTRAWHITE in the pyrex source with BB_ENV_PASSTHROUGH_ADDITIONS.
   • This should be quick and easy, but would un-support versions of bitbake prior to 2.0 in the pyrex mainline. Since pyrex doesn't have stable branches, any users who remain on older bitbake versions will have to backport future pyrex changes to their own fork.
3. Introspect the version of bitbake in-use at container-start-time and use the correct variable name for the bitbake version.
   • This would shield users from the impact of the inclusive naming changes, and enable them to continue using EXTRAWHITE. But this might be doing them a disservice in the long term by hiding the incompatibility.
   • This also implies breaking the encapsulation of pyrex' responsibilities, and making assumptions about their bitbake setup - which is probably not desirable.

[denix0]

FYI
#76