devVersions arch token hardcoded to amd64/x86_64 — breaks RedHat-family arm64 dev builds

[bschwedler]

Problem

_make_resolver_metadata hardcodes arch_identifier based on OS family, with no per-platform branch at all:

arch_identifier = "amd64"
if _os.family == OSFamilyEnum.REDHAT_LIKE:
    arch_identifier = "x86_64"

architecture_generalized_download_url then does a naive string-replace of whichever token appears in the resolved concrete URL with the literal placeholder $TARGETARCH, relying on Docker's build-time ARG TARGETARCH to refill it. That only works for Debian-like OSes because Docker's TARGETARCH vocabulary (amd64/arm64) happens to equal Debian's dpkg vocabulary. RedHat's real convention (x86_64/aarch64) diverges from Docker's for both architectures, so any multi-platform RedHat-family devVersion produces a 404 regardless of whether the artifact exists.

Confirmed directly against the CDN for package-manager (both the failing 2026.06.0 dev build and the already-released 2026.05.0):

Token	Result
rpm/amd64/...amd64.rpm	404
rpm/arm64/...arm64.rpm	404
rpm/x86_64/...x86_64.rpm	200
rpm/aarch64/...aarch64.rpm	200

There's a standing FIXME acknowledging the gap:

# FIXME: This does not take into account RHEL-based OS notations (x86_64 or aarch64). These may need to be set at
#        buildtime using bash expressions.

SUSE_LIKE isn't special-cased either, despite also producing .rpm (packageSuffix) — it would silently fall through to the amd64 default.

Where

• posit_bakery/config/image/posit_product/main.py: _make_resolver_metadata (arch_identifier hardcoding), ReleaseChannelResult.architecture_generalized_download_url (the generalize step)
• Called from dev_version/channel.py (_resolve_os_urls, get_url_by_os) and duplicated in dev_version/base.py, gated on platforms != DEFAULT_PLATFORMS

Trigger

Surfaced by posit-dev/images-package-manager#103 adding RHEL 10 as a multi-platform devVersion OS:

• https://github.com/posit-dev/images-package-manager/actions/runs/29534302493/job/87741896666

Possible directions

• Replace the hardcoded default with an explicit family × platform → arch-token map, so aarch64 is derived instead of assumed.
• Or: keep $TARGETARCH as the Containerfile-side placeholder, but resolve it via a build-time OS-family-aware translation (bash case statement mapping amd64/arm64 → x86_64/aarch64 for RPM), matching what the FIXME already suggests.
• Extend the existing artifact-availability probe (HEAD request / ArtifactNotAvailableError, same file) to run per-platform when generalization is used, so a wrong token 404s at bakery build --plan time instead of deep in a Docker build.

Related

• Use devVersion OS config when creating new versions #412