Probably arch should be optional here, you may break API compatibility by adding it as required positional argument

Probably arch should be optional here, you may break API compatibility by adding it as required positional argument

Updated.

One thing I see is that a call to get_rpm_arch() is not changed - so profile selection isn't going to work properly.

Three different architectures names - Flatpak, RPM, and Docker/OCI. I believe that for the architectures that we build containers for Fedora and RHEL, the flatpak and RPM names are always the same: x86_64, ppc64le, s390x, aarch64 - compared to amd64, ppc64le, s390x, arm64 for Docker - but I wouldn't want to assume that in the API.

What I'd like to see is along the lines of:

FlatpakBuild(..., oci_arch=None)
if oci_arch:
    self.flatpak_arch, self.rpm_arch = _ARCH_MAP[oci_arch]
else:
    self.flatpak_arch = get_flatpak_arch()
    self.rpm_arch = get_rpm_arch()

Beyond that - my big question is "does it work?" I assume that the idea here is that the flatpak-module-tools code is running on a different architecture than the target architecture - so do any of the:

flatpak build-bundle
flatpak build-init
flatpak build-finish

calls that this code is make assumptions about current architecture? This should be testable by adding to tests/test_flatpak_build.py a test that builds for "fakearch". Unfortunately, the code to unpack the OCI and extract metadata from the labels and from the filesystem tree is going to be moderately complex, but I think it's worth it to regressing here.

If this seems to hard, then I can deal with adding the tests.

Superceded by #16