pyrex: replace BB_ENV_EXTRAWHITE with BB_ENV_PASSTHROUGH_ADDITIONS

[denix0]

As part of OE-Core/Bitbake inclusive language variable renames.

Signed-off-by: Denys Dmytriyenko denis@denix.org

[amstewart]

Endorsed!

But is there a reasonable way for the capture module to support both generations of bitbake? My org will soon be maintaining two concurrent mainlines, one on bitbake 1.38 and the other on >2.0. I'd like to be able to continue using the pyrex master ref on the old bitbake, if possible.

Maybe pyrex can prefer to use whichever whitelist variable is defined within the container-host environment? Then at least the user can fixup their host to match their bitbake version.

[denix0]

Endorsed!

But is there a reasonable way for the capture module to support both generations of bitbake? My org will soon be maintaining two concurrent mainlines, one on bitbake 1.38 and the other on >2.0. I'd like to be able to continue using the pyrex master ref on the old bitbake, if possible.

Maybe pyrex can prefer to use whichever whitelist variable is defined within the container-host environment? Then at least the user can fixup their host to match their bitbake version.

FWIW, this is exactly the reason it hasn't been merged for 7 month.

My workaround - I use my fork with the patch applied for Kirkstone+ projects, and use the original for Dunfell- projects otherwise.

I hope @JoshuaWatt is able to figure out how to handle this :)

[JoshuaWatt]

Endorsed!
But is there a reasonable way for the capture module to support both generations of bitbake? My org will soon be maintaining two concurrent mainlines, one on bitbake 1.38 and the other on >2.0. I'd like to be able to continue using the pyrex master ref on the old bitbake, if possible.
Maybe pyrex can prefer to use whichever whitelist variable is defined within the container-host environment? Then at least the user can fixup their host to match their bitbake version.

FWIW, this is exactly the reason it hasn't been merged for 7 month.

My workaround - I use my fork with the patch applied for Kirkstone+ projects, and use the original for Dunfell- projects otherwise.

I hope @JoshuaWatt is able to figure out how to handle this :)

Yep, it's on the TODO list; I was hoping we could figure out a way to do it without make separate releases, but I'm just not sure if that's going to work. If anyone has any ideas to make it work, let me know.

[JoshuaWatt]

I believe this is resolved by #81 Please confirm and close if so