Adopt PURL Metadata
Summary
Package metadata will be enhanced by adding virtual Provides for standardized identifiers based on the PURL (Package-URL) specification, with the goal of simplifying the mapping between upstream projects and Fedora packages.
Owner
- Name: Fabio Valentini
- Email: decathorpe AT gmail DOT com
Current status
- Targeted release: Fedora Linux 45
- Last updated: 2026-07-21
- devel-announce post
- Discussion thread
- FESCo issue: #3617
- Tracker bug: #2494983
- Release notes tracker: #411
Detailed Description
The Package-URL (PURL) standard privides a "standardized URL-based syntax that uniquely identifies software packages, independent of their ecosystem or distribution channel" (from the project README).
It is being adopted by many projects across the ecosystem - including the CycloneDX and SPDX SBOM formats, various software vulnerability databases, and the CVE Record Format (added as an optional field in version 5.2.0).
By adding virtual Provides for these standardized identifiers to Fedora packages, it becomes easier to map upstream projects to packages - for example, to identify which packages are affected by a security vulnerability.
The PURL standard defines this URL scheme:
scheme:type/namespace/name@version?qualifiers#subpath
For many "types" of packages, RPM generators already add virtual "Provides" for packages (for example, crate(libc) = 0.2.186 or rubygem(kramdown) = 2.5.2) - but this is a downstream-specific format.
The RPM generators for package ecosystems that are supported by the PURL specification will be extended to also add metadata in the PURL format (like purl(pkg:cargo/libc@0.2.186) or purl(pkg:gem/kramdown@2.5.2). The next package rebuild after the necessary RPM generator changes land will include this new metadata.
This could then be extended to bundled(...) virtual Provides as well, which are currently even more heterogeneous since there's no standardized format for them in Fedora, and could potentially replace existing non-standard bundled(...) Provides in many cases.
The initial target of this Change is to start adding virtual Provides in PURL format for packages in the following language ecosystems:
- "cargo" (Rust crates)
- "cpan" (Perl packages)
- "cran" (R packages)
- "gem" (RubyGems)
- "hackage" (Haskell packages)
- "maven" (Java packages)
- "npm" (NodeJS / NPM packages)
- "opam" (OCaml packages)
- "pypi" (Python packages from PyPI)
Currently, the only supported PURL "type" for C/C++ projects appears to be "conan", which is not useful in this context, but new types are getting added to the spec regularly.
This will likely be an iterative process and the necessary changes might not happen for all language ecosystems in just one release cycle.
Feedback
TBD
Benefit to Fedora
This Change aims at making it easier and more reliable to identify which packages contain code from what projects. This allows for more reliable identification of packages affected by security vulnerabilities. Additionally, this metadata might be interesting for generating SBOMs for content included in (container) images.
Scope
- Proposal owners:
Implement adaptations for RPM generators to emit the new virtual Provides.
- Other developers:
Review and apply changes to RPM generators and other packages, where necessary.
- Release engineering: #13347
This Change requires a mass rebuild for affected packages to get the new metadata.
- Policies and guidelines:
Update Packaging Guidelines to recommend attaching metadata in PURL format to packages, where possible (to be determined if this also applies to bundled(...) Provides).
FPC Ticket: https://forge.fedoraproject.org/packaging/guidelines/issues/1536
- Trademark approval:
N/A (not needed for this Change)
- Alignment with the Fedora Strategy:
N/A (not needed for this Change)
Upgrade/compatibility impact
This Change only provides additional package metadata and should have no effect on upgrades or backwards compatibility.
Early Testing (Optional)
N/A
Do you require 'QA Blueprint' support? N
How To Test
Packages that are rebuilt after these changes land should have additional RPM Provides. This can be verified by running something like dnf --provides perl-Errno and looking for an entry in the purl(...) format.
User Experience
No direct impact to user experience is expected.
However, easier identification of packages that are affected by security vulnerabilities should enable fixes for these issues to happen more reliably (and potentially faster).
Dependencies
Direct dependencies:
- Packages that contain the RPM generator implementations
Indirect dependencies:
- Everything.
Contingency Plan
This is a purely additive and / or metadata-only Change. If the necessary changes are not finished by the mass rebuild date, they can still land at a later point in time, but will only affect a subset of packages. For best results, the changes should land before the Mass Rebuild, but this is not strictly necessary.
- Contingency mechanism:
Changes do not need to be reverted. If changes are not complete before the mass rebuild, it might need to be documented that the Change will only be partially implemented for the targeted Fedora release, and that only the next release will benefit fully.
- Contingency deadline:
Mass rebuild.
- Blocks release?
No.
