No support for reactive charms with multiple bases about release-tools HOT 2 OPEN

build-on(amd64) but run-on(s390x, ppc64el,arm64) I believe is also not be valid for much the same reason.

It works for arch-independent wheels but any wheel with a binary component will fail. Given the dependency graph of bases and their dependencies it may not be possible to reason about whether any given charm includes binary components?

From my current understanding I am told that Launchpad can remote-build charms (similar to snaps) but only using Launchpad recipes and there is not currently an equivalent to "snap remote-build" or the ability to cross compile (though there is some prior art for cross compiling wheels at https://github.com/benfogle/crossenv)

In any case the same fix here will make it so that multiple architectures can be built but the machinary to aquire and build it on those architectures and get the files all together for upload may be additional work. Unclear to me if that needs to be filed as a separate bug somewhere or if any charms are currently affected by this.

from release-tools.

For Classic charms, only Python source code is shipped and any Python dependencies come from installed debs. For Reactive charms the charm tools ensure that only source wheels are distributed and any dependencies requiring building will be built at install time. Both of these mechanisms have their problems and drawbacks.

For Operator Framework machine charms we hopefully can get rid of that madness and rely on launchpad built binaries, but we do indeed need some CI fixes to cope with that too.

from release-tools.