`@multitool//tools/<tool>` can resolve host arch instead of target arch in packaging (rules_oci) use cases

[hunshcn]

Hi, thanks for rules_multitool.

We found that when @multitool//tools/tini:tini is used as an artifact input (e.g. pkg_tar / rules_oci image contents), resolution may pick host-arch binary instead of target-arch binary.

On an arm64 host:

• building for linux_amd64 may still pick linux_arm64 tini
• building for linux_arm64 picks linux_arm64 (expected)

This makes multi-arch image contents non-deterministic for target platform.

Debug example:

  bazel aquery \
    --platforms=@rules_go//go/toolchain:linux_amd64_cgo \
    '--toolchain_resolution_debug=.*' \
    @multitool//tools/tini:tini

In our case it selects:

• ...:tini_linux_arm64_toolchain_info
• input ...multitool.tini.linux_arm64/.../linux_arm64_executable

Could you provide a target-arch-stable path for packaging scenarios?
For example:

• separate labels/APIs for exec vs target resolution, or
• an option to generate/register target-only toolchains for specific tools.

[markelliot]

Hm, the toolchains are architecture tagged, so the resolution should be correct here if the appropriate constraints are supplied.

[hunshcn]

Hm, the toolchains are architecture tagged, so the resolution should be correct here if the appropriate constraints are supplied.

To clarify, the issue with the current “single label + mixed exec/target registrations” model is:

• It is host-dependent for artifact packaging: on arm64 host, --platforms=linux_amd64 can still resolve @multitool//tools/tini:tini to arm64.
• It is not deterministic across environments (different host arch / local vs remote execution may pick different binaries).
• It conflates two intents that users need to control separately:
  • “I need a binary to run on the exec platform”
  • “I need a file matching the target platform to package into an artifact/image”
• In multi-arch image workflows (rules_oci), this can produce wrong image contents for one of the target architectures.

So even with one toolchain type, the current mixed registration (exec_compatible_with + target_compatible_with for the same label/type) is the problematic part.

I don't know if there is a better way, but according to my knowledge, it seems that only exec toolchain and target toolchain can be distinguished.

[hunshcn]

@markelliot WDYT

[hunshcn]

duplicated to #104

Let's discuss it there