`azure-cli` not available in MSFT Fedora 44 repo

[cflanderscpc]

Describe the bug

When adding the packages.microsoft.com repo to Fedora, azure-cli is not available for installation. The version currently packaged in Fedora 44's downstream repo is out of date.

Related command

az --version

sudo dnf info azure-cli

Errors

No error message. Package does not exist at https://packages.microsoft.com/fedora/44/prod/Packages/a/

Issue script & Debug output

n/a

Expected behavior

that an up to date azure-cli package would exist in the provided Fedora repo.

Environment Summary

Fedora 44 with MSFT Prod yum repo added

Additional context

I don't know if this was the right place to open an issue. None of the documentation mentions anything about using the RHEL or CentOS repos instead, and given a Fedora repo does exist, it makes sense that CI release workflows could technically populate it as well, which would be less confusing.

[yonzhan]

Thank you for opening this issue, we will look into it.

[x-engineering-agent]

Bug Analysis

Assessment: Sufficient reproduction information for an RPM distribution/build investigation. This is a package-availability problem before Azure CLI execution, not a failure in an Azure service command.
Target: Azure/azure-cli, base branch dev, repository-level RPM packaging/release engineering. Repository-aware inference returned unknown (no command module or extension), so retain the issue here; no extension tracker is appropriate.
Use this EXACT PR title: [Packaging] Fix #34131: az --version: Enable Fedora 44 RPM build and validation

Reported reproduction and expected behavior

• Platform/context: Fedora 44 with Microsoft's production yum repository configured. The reporter says Fedora's downstream azure-cli package is outdated.
• Exact package lookup supplied: sudo dnf info azure-cli. Related CLI command supplied: az --version; it is the eventual installation smoke check, not an observed crashing command.
• Actual behavior: the reporter cannot find an azure-cli package in Microsoft's Fedora 44 production feed. No error message or stack trace was reported. This report does not establish that dnf info cannot find a Fedora-maintained package from another enabled repository.
• Expected behavior: an up-to-date Microsoft-published azure-cli RPM is discoverable/installable from the configured Fedora 44 feed.
• A CLI version is not necessary to investigate a package absent before installation. Fedora 44 plus the repository context and exact lookup provide the relevant reproduction context. Feed contents have not been independently verified here, and no local command, test, build, or release was run.

Current source evidence

Inspected dev at 9a3432d5ce7ebcbc5473b994897ab16ae998878b:

1. azure-pipelines.yml, RPM build matrix builds UBI 8/9/10 RPMs for the configured architectures; there is no Fedora entry. The matching installation-test matrix similarly covers those UBI artifacts, not Fedora 44. Azure Linux has separate jobs; preserve them.
2. scripts/release/rpm/fedora.dockerfile exists but defaults to Fedora 35, uses the configurable python_package with PYTHON_CMD=python3, and smoke-tests only installation of a locally built RPM plus az --version. Its existence does not establish Fedora 44 support or feed publication.
3. scripts/release/rpm/pipeline.sh accepts the Dockerfile, image and Python package, builds the RPM and copies it into staging. PublishPipelineArtifact in the YAML publishes an Azure Pipelines artifact, not a package into a Microsoft production feed.
4. scripts/release/rpm/azure-cli.spec derives its Python runtime/build dependencies from the supplied Python package/command; its installation section builds a venv and the launcher. Fedora's real Python/package layout must be validated rather than copying UBI's python3.12 assumptions.
5. test_rpm_in_docker.sh installs a local RPM and runs the existing package checks. verify_rpm_in_docker.sh instead checks a hard-coded generic Azure CLI yum repository, so neither currently verifies Fedora 44 feed availability. The RPM README also retains Fedora 29 examples.

Diagnosis and ownership boundary: The inspected source confirms a missing Fedora 44 build/test path and a gap in Fedora-specific repository verification. It does not prove where Microsoft production signing/publication is configured, whether Fedora 44 is an approved release destination, or that changing a Dockerfile alone would populate that feed. Treat publication/support approval as a release-owner dependency, not as an already-verified code defect or an authorization to change a production service.

Proposed focused fix for the durable implementation job

1. Trace the existing, trusted RPM release configuration to identify the approved Fedora 44 signing/publication destination and owning release process. Do not infer a writable destination or permission from the issue's URL. If that configuration/approval is external or unavailable, report the concrete release-owner dependency and stop before claiming the availability bug is fixed; do not manufacture a publisher, credentials, a new service endpoint, or an unsupported RHEL/CentOS workaround.
2. Within that approved release path, add a matching Fedora 44 build/install-test entry to the existing RPM pipeline using fedora.dockerfile, a verified Fedora 44 image/Python combination, architecture-specific artifact naming, and the Fedora RPM distro suffix. Keep build/test artifact names aligned and retain existing UBI/Azure Linux behavior and existing pipeline trigger conditions. Adjust only Fedora-specific Dockerfile/spec compatibility proven necessary; preserve build-argument overrides.
3. Connect the resulting Fedora artifact to the existing approved publication mapping where that mapping is repository-owned. Distinguish artifact creation, signed publication, and post-publication verification. A new matrix entry or README change alone is not acceptance of the reported missing-package fix. No release/publish workflow or production repository mutation is authorized during implementation validation.
4. Extend the existing RPM repository-verification path narrowly so a maintainer-controlled Fedora 44 scenario checks the selected feed's package origin and requested release version, rather than accidentally passing on Fedora's older downstream package, a preinstalled CLI, or a different enabled feed. Preserve GPG/signature verification for repository installs; do not carry unsigned-local-artifact test options into production-feed validation.
5. Update the existing RPM README's affected Fedora examples and clearly distinguish local build capability from actual Microsoft feed publication/support. Keep changes scoped to RPM packaging, its pipeline integration, relevant existing documentation and focused coverage; no unrelated CLI command changes.

Regression/scenario coverage required in the job

• Validate the paired Fedora 44 build/test configuration, architecture and distro-suffix artifact selection, and consistent Python package/executable/pip settings using the repository's existing validation mechanisms.
• In an isolated Fedora 44 environment, exercise the existing local RPM installation/package checks and az --version (plus the existing az self-test check); verify the built CLI version and runtime dependencies. Validate with existing RPM tools/tests, not a newly invented test framework.
• Describe and cover repository-verification success for the intended version/origin and failure for a missing package, an older version, or a package available only in an unrelated/downstream feed. Local artifact installation is not evidence that the public feed is populated.
• Preserve and check existing UBI RPM scenarios and Azure Linux configuration; ensure defaults remain backward-compatible for existing callers. Document the Fedora repository acceptance scenario for the release owner to run after approved publication; do not start or wait for a release from this job.
• Record the actual validation results or precise blockers. This triage has not run any of these tests.

Source-generation classification and execution boundaries

The evidenced files are handwritten packaging scripts, a Dockerfile/spec and pipeline YAML, not AAZ-generated command output. No command model or generated module edit is proposed. The deterministic Codegen protocol below applies if investigation genuinely crosses that boundary; it is not a request to create/regenerate an unrelated packaging command module. Never hand-edit aaz/<profile>/ output. If generated behavior is implicated, change its owned durable input and use the approved regeneration workflow, or stop with a blocker.

Implementation is delegated only to the durable Foundry job through the compatibility dispatch helper and trusted publication. Do not independently assign a bot, start hosted Agent Tasks, post an execution mention, use another provider, or invoke a retired fork-promotion flow.

Mandatory Codegen execution protocol

Before editing implementation files, determine whether the affected packaging command is AAZ-generated. Files under aaz/<profile>/ are generated output and must never be patched directly, including by an AI agent. Check out Azure/aaz beside Azure/azure-rest-api-specs, Azure/aaz-dev-tools, and the downstream repository. API-schema defects start in the specification; command naming, grouping, arguments, API-version selection, help, and examples belong in the durable Azure/aaz command model; non-modelable client behavior belongs in a handwritten subclass or wrapper in custom.py, registered from commands.py. X Engineering Agent creates and promotes the corresponding durable Azure/aaz source pull request before it promotes downstream generated output.

Follow the Azure CLI repository's Codegen workflow and the aaz-dev setup documentation. Set up the checked-out repositories with azdev setup. Use generate only when importing or redesigning command models from Swagger/TypeSpec. For an existing module whose durable Azure/aaz model has been updated, render that model with regenerate:

aaz-dev cli regenerate --name packaging --cli-path <azure-cli>

# New/imported command model only:
aaz-dev cli generate --spec <specification-name> --module packaging

You MUST actually run the generator; do not merely describe it or imitate its output. If the AAZ/specification checkout, local source change, credentials, or generator is unavailable, stop and report the blocker instead of editing generated files. Inspect _aaz_info provenance and the complete regenerated diff, then run focused azdev style, azdev linter, and azdev test validation. For an extension, also update its version and HISTORY.rst, preserve azext_metadata.json compatibility, and let release automation update src/index.json.

PR title & description format (required)

This repo enforces a PR format (guide). Please author the PR exactly as follows or CI's Check the Format of Pull Request Title and Content will fail.

Use this EXACT PR title (copy verbatim, do not reword):

[Packaging] Fix #34131: `az --version`: Enable Fedora 44 RPM build and validation

Keep the backticks around the command and the Fix #34131: prefix. You may only adjust the wording after the command (the final summary) if the fix changes; the [Packaging] prefix, issue link, and backticked command must stay.

Description — follow the PR template and fill in:

• Link the issue — start the Description with a closing keyword so the PR auto-links and closes it: Fixes #34131.
• Related command — the az ... command this affects.
• Description (mandatory) — why the bug happens, what you changed, and the resulting behavior.
• Testing Guide — example command(s) showing the fix works.
• History Notes — leave the title to drive the history note, or add extra lines in the same format (component in brackets + the command in backticks), e.g. [Packaging] `az <command>`: <note>.
• Keep the template checklist and tick the items you've satisfied.