Skip to main content
Azure Linux uses RPM (Red Hat Package Manager) as its package management system. All packages are built from SPEC files that define how software is compiled, packaged, and installed on the system.

​
Package Organization

Azure Linux packages are organized into two main directories:

SPECS

Production-ready packages with full support and timely CVE maintenance

SPECS-EXTENDED

Experimental packages for proof-of-concept and staging purposes

​
Package Directory Structure

Each package lives in its own subdirectory to avoid naming conflicts: 
SPECS/
├── curl/
│   ├── curl.spec
│   ├── curl.signatures.json
│   └── CVE-2025-0665.patch
├── nginx/
│   ├── nginx.spec
│   ├── nginx.signatures.json
│   └── nginx.service
└── python3/
    ├── python3.spec
    ├── python3.signatures.json
    └── cgi3.patch

​
Key Components

​
SPEC Files

SPEC files contain all the metadata and instructions needed to build an RPM package:
  • Package metadata (name, version, license, description)
  • Build dependencies and runtime requirements
  • Source file locations and patches
  • Build, installation, and testing instructions
  • File lists for the resulting packages
  • Changelog entries

​
Signature Files

Each SPEC file is accompanied by a *.signatures.json file that records SHA-256 hashes of all source files. This ensures source integrity and prevents unauthorized modifications. 
{
  "Signatures": {
    "curl-8.11.1.tar.gz": "1234567890abcdef..."
  }
}

​
Build System Workflow

The Azure Linux build system follows this workflow:
1

SPEC File Creation

Package maintainers create or update SPEC files with build instructions
2

Source Validation

The srpmpacker tool validates source files against signature hashes
3

SRPM Generation

SPEC files and sources are packaged into Source RPMs (SRPMs)
4

Binary Package Build

SRPMs are compiled in isolated build environments to create binary RPMs
5

Testing

Packages run through the %check section for validation

​
Package Support Levels

DirectoryPublishedSupportedRequirements
SPECSYesYes- Viable upstream source with active CVE management
- No project-specific code
- Value for multiple use cases
SPECS-EXTENDEDYesNo- Viable upstream source with active CVE management
- No project-specific code
- Can be used for staging packages
Packages in SPECS-EXTENDED can be graduated to SPECS after demonstrating their value and completing additional quality requirements.

​
Common Package Operations

​
Installing Packages

Azure Linux uses tdnf (Tiny DNF) as its package manager: 
# Install a package
tdnf install curl

# Update a package
tdnf update curl

# Remove a package
tdnf remove curl

# Search for packages
tdnf search nginx

​
Querying Package Information

Use rpm commands to query package details: 
# List installed packages
rpm -qa

# Show package information
rpm -qi curl

# List files in a package
rpm -ql curl

# Find which package owns a file
rpm -qf /usr/bin/curl

​
Source Management

Package sources can be hosted in two locations:
  1. Azure Linux Source Server: https://azurelinuxsrcstorage.blob.core.windows.net/sources/core/
  2. Local SPECS Directory: SPECS/<package>/ for small patches and configuration files
Large source archives should be hosted on the source server. Only small files like patches should be stored directly in the SPECS directory.

​
Next Steps

SPECS vs SPECS-EXTENDED

Understand the differences between package directories

Creating SPEC Files

Learn how to write RPM SPEC files

Package Repository

Explore the repository structure and organization

Build docs developers (and LLMs) love

Get started for freeTalk to us