We should have target-archtiecutre for subpackages

[justinvreeland]

Sometimes the subpackages from a packages are not the same on both architectures. We should be able to mark packages as x86_64 or arm64 only.

[dustinkirkland]

Supporting evidence from chainguard-dev/stereo

A scan of the three package trees in chainguard-dev/stereo (os/, extra-packages/, enterprise-packages/) shows this is a real and widespread gap.

Current workaround: if: ${{build.arch}} on pipeline steps

49 YAML files (102 individual occurrences) work around the missing feature by guarding pipeline steps inside subpackages with if: ${{build.arch}} == "..." conditions. Examples:

os/dart.yaml — arch-specific build commands inside a subpackage pipeline:

  - if: ${{build.arch}} == "x86_64"
    runs: |
      ./tools/build.py --mode release --arch x64 create_sdk
      mv out/ReleaseX64/dart-sdk ${{targets.destdir}}/usr/lib/dart

  - if: ${{build.arch}} == "aarch64"
    runs: |
      ./tools/build.py --mode release --arch arm64 create_sdk
      mv out/ReleaseARM64/dart-sdk ${{targets.destdir}}/usr/lib/dart

enterprise-packages/aws-lc-fips.yaml — arch-specific cmake configure flags inside a subpackage pipeline:

  - if: ${{build.arch}} == 'aarch64'
    uses: cmake/configure
    with:
      opts: -DCMAKE_INSTALL_LIBDIR=lib/aws-lc ...

  - if: ${{build.arch}} == 'x86_64'
    uses: cmake/configure
    with:
      opts: -DCMAKE_INSTALL_LIBDIR=lib/aws-lc -DENABLE_FIPS_ACVP_TESTS=1 ...

Cases where the workaround is insufficient

The if: guard handles arch-specific steps inside a subpackage, but it cannot suppress the subpackage itself (its name, metadata, and APK) from being emitted on architectures where it has no meaningful content.

A current example is enterprise-packages/grub.yaml: the grub-efi and grub-efi-libs subpackages are EFI-specific and conceptually x86_64/aarch64 UEFI targets, but there is no way to express "don't produce this subpackage APK on architectures where EFI doesn't apply" — the package is built for all architectures the parent targets.

What's available today at the top-level

target-architecture works at the package level and 48 YAML files use it to restrict which architectures a whole package builds for. Extending this field to the Subpackage struct (currently additionalProperties: false in the JSON schema) would close the gap and allow the 49 workaround files to express their intent more clearly and correctly.