Resolves the in-repo half of #24076 (DSR for Debian 12 arm64). We already
build a `linux-arm64` self-contained binary and a `tar-arm64` tarball, but
the only `.deb` we ship is `amd64`. This adds a `deb-arm64` packaging
path that consumes the existing arm64 signed binary drop and emits a deb
whose control field reports `Architecture: arm64` and whose filename
ends in `_arm64.deb`.
The packaging logic itself was almost free — `New-DebPackage` already
takes `HostArchitecture` and writes it verbatim into the deb control
file and output filename, and Debian uses `arm64` natively (no `aarch64`
translation like RPM needs). So the new switch arm in `Start-PSPackage`
is a clone of `'deb'` with `HostArchitecture = "arm64"`.
Pipeline-side:
- `linux-package-build.yml` learns the `deb-arm64` packageType and maps
it to the `Signed-linux-arm64` drop folder
- `PowerShell-Packages-Stages.yml` adds a `deb_arm64` job that consumes
the existing `drop_linux_build_linux_arm64` /
`drop_linux_sign_linux_arm64` artifacts (the same ones feeding
`tar-arm64` today)
- `release-validate-packagenames.yml` widens the deb regex from
`_amd64\.deb` to `_(amd64|arm64)\.deb`
I deliberately did not set `hostArchitecture: arm64` on the new job's
pool. Per OneBranch's ARM64 Build Hosts guidance, that flag is for
native compilation of arm64 code; we're just running `dpkg-deb` over
already-built arm64 binaries, which is what `tar-arm64` does today on
the default amd64 linux pool. The existing signing step's
`files_to_sign: '**/*.rpm;**/*.deb'` glob already picks up the new
artifact with no change.
The remaining DSR checklist items (Docker image in
PowerShell/PowerShell-Docker, PMC publish, lifecycle and install-doc
updates in MicrosoftDocs/PowerShell-Docs) live outside this repo and
are tracked on #24076.
Drafted by Copilot (Claude Opus 4.7 (High reasoning)).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
