Skip to main content
Azure Linux organizes packages into two directories with different support levels and requirements. Understanding these differences is crucial for package maintainers and contributors.

​
Directory Comparison

SPECS

Production-ready packages with full support, timely CVE patches, and quality guarantees

SPECS-EXTENDED

Experimental packages for proof-of-concept, testing, and staging before promotion

​
Detailed Comparison

FeatureSPECSSPECS-EXTENDED
Published✅ Yes✅ Yes
Supported✅ Yes❌ No
CVE MaintenanceTimely patches requiredBest effort only
Quality RequirementsStrictRelaxed
Use CasesProduction systemsDevelopment, experimentation
Viable Upstream✅ Required✅ Required
Project-Specific Code❌ Not allowed❌ Not allowed
Multiple Use Cases✅ RequiredNot required

​
SPECS Directory

The SPECS directory contains packages that meet Azure Linux’s production quality standards.

​
Requirements

The package must have an active upstream project that:
  • Regularly releases security updates
  • Actively addresses CVE reports
  • Maintains source code availability
  • Provides reasonable support for users
Packages must be general-purpose software, not custom code for specific projects or organizations. This ensures broad applicability.
The package should provide value across different scenarios and user groups, not just a single narrow use case.
Packages must include a %check section in the SPEC file that validates functionality during builds.

​
Example Packages

SPECS/
├── curl/          # HTTP client library - widely used
├── nginx/         # Web server - production workloads
├── python3/       # Programming language - broad utility
├── openssl/       # Cryptography library - core dependency
└── systemd/       # Init system - system critical

​
SPECS-EXTENDED Directory

The SPECS-EXTENDED directory serves as a staging area and experimental zone for packages.

​
Use Cases

New Package Testing

Test new packages before promoting to SPECS

Experimental Features

Try cutting-edge versions or experimental builds

Niche Software

Packages useful for specific scenarios

Development Tools

Tools needed for development but not production

​
Requirements

Viable upstream source with active CVE management
No project-specific code
No guarantee of CVE patching timeline
May be removed without notice if inactive

​
Example Packages

SPECS-EXTENDED/
├── 389-ds-base/      # LDAP server - specialized use
├── CharLS/           # JPEG-LS library - niche codec
├── GeoIP/            # IP geolocation - specific feature
└── PEGTL/            # Parser library - development tool

​
Package Graduation Process

Packages can be promoted from SPECS-EXTENDED to SPECS when they demonstrate value and meet requirements.
1

File a GitHub Issue

Create an issue explaining the package’s value and broader use cases
2

Increment Release Version

Update the Release field in the SPEC file
3

Add Changelog Entries

Document the promotion with these entries:
  • “Package promoted from SPECS-EXTENDED to SPECS”
  • “License verified”
4

Add or Verify Tests

Ensure a comprehensive %check section exists and passes
5

Clean Up SPEC File

Remove references, macros, or comments specific to other distributions
6

Submit Pull Request

Create PR with graduation changes and complete the PR checklist
7

Pass GitHub Checks

All automated checks must pass before merge

​
Example Graduation PR Changes

Summary:        Example package description
Name:           example-package
Version:        1.2.3
-Release:        1%{?dist}
+Release:        2%{?dist}
License:        MIT

%changelog
+* Mon Feb 20 2026 Your Name <[email protected]> - 1.2.3-2
+- Package promoted from SPECS-EXTENDED to SPECS
+- License verified
+
* Fri Jan 15 2026 Original Author <[email protected]> - 1.2.3-1
- Initial package

​
Choosing the Right Directory

Use this decision tree to determine where your package belongs:
Start in SPECS-EXTENDED if you’re unsure. You can always graduate packages later after proving their value and stability.

​
Best Practices

For SPECS Packages

  • Monitor CVE databases regularly
  • Keep patches up-to-date
  • Maintain comprehensive tests
  • Document all changes thoroughly

For SPECS-EXTENDED Packages

  • Mark experimental status clearly
  • Document known limitations
  • Track graduation criteria
  • Keep upstream in sync

​
Common Questions

While SPECS-EXTENDED packages are published and installable, they are not recommended for production use because they lack guaranteed CVE support and may have stability issues.
Graduation timeline depends on:
  • Complexity of the package
  • Quality of test coverage
  • Review team availability
  • Community feedback
Expect 2-4 weeks for most packages.
If upstream becomes inactive or stops addressing CVEs, the package may be:
  • Moved to SPECS-EXTENDED
  • Replaced with an alternative
  • Removed entirely (with advance notice)
Yes, packages can be demoted if they:
  • Lose active upstream maintenance
  • No longer provide broad value
  • Have persistent quality issues
  • Are replaced by better alternatives

​
Next Steps

Creating SPEC Files

Learn how to write RPM SPEC files for both directories

Package Repository

Understand the repository structure and organization

Build docs developers (and LLMs) love

Get started for freeTalk to us