[RFC] dev-lang/python-oem: use python from python-build-standalone project

[jepio]

dev-lang/python-oem: use python from python-build-standalone project

Our python-oem is minimal and doesn't support pip or most of the standard
library. This is an attempt to see whether using a prebuilt python
distribution works to support Azure extensions.

It was necessary to add a symlink to 'python' executable and lib64 dir to avoid
having to change distro-oem and waagent ebuilds.

How to use

Test on Azure, deploy VMBackup/VMSnapshot extension from Azure portal.

Testing done

[Describe the testing you have done before submitting this PR. Please include both the commands you issued as well as the output you got.]

• Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)

[pothos]

These are the binary releases, or? I think it's ok to use binary releases if we have some criteria but at the moment we normally compile from source (also possible for this project).
So that's more a general question worth discussing: under which circumstances are we fine consuming third-party binaries, and if it's an option, should we plan to do more of it to lower the maintenance burden and build times? E.g, there are binary releases for the Rust compiler or Go, why not use them, too?

[jepio]

Yes these are binary releases. Normally I prefer the build from source approach, but it wouldn't be possible to do that from the ebuild here:

The execution environment must have access to a Docker daemon (all build operations are performed in Docker containers for isolation from the host system).

Though we could rebuild from source and host the binaries for ourselves, and then consume them.

E.g, there are binary releases for the Rust compiler or Go, why not use them, too?

I would be for switching to dev-lang/rust-bin, the build times for it are ridiculous, and the rust compiler (including self bootstrap) is a major part of our SDK build time. For go we wouldn't have much benefit from using a pre-built toolchain.

[pothos]

Also given that we can revisit the choice of where the python binaries come from when migrating to sysext, I'm fine consuming the published binaries in this case here.

About Rust, yeah, specially the LLVM compilation takes ages…

[jepio]

Rust cross-compilation support is something we handle in dev-lang/rust and would need to be ported. I haven't looked deeper.

[pothos]

Yeah, or use rustup to install the regular toolchain into the SDK

[pothos]

Suggested change

	find ${ED} -name 'lib*.a' -delete
	find ${ED}/usr/share/oem/python/ -name 'lib*.a' -delete

[krnowak]

I'm not sure I like the fact that we are pulling binaries from some random place. How does this play with the secure supply chain initiative?

[jepio]

That's why I wanted to have this discussion, this is not something I want to merge as is. At very least we should rebuild the binaries ourself.

Do you have ideas for alternative approaches that I could explore?

[pothos]

Do you have ideas for alternative approaches that I could explore?

Maybe we can prioritize the OEM sysext transition over Docker sysext and start with Azure?