packaging/guidelines

Fork 15

Packaging Guidelines changes for Change: Adopt PURL Metadata #1536

New issue

Open

opened 2026-05-07 13:53:04 +00:00 by decathorpe · 2 comments

decathorpe commented

2026-05-07 13:53:04 +00:00

Owner

I'm in the process of submitting a Change proposal that has the goal of adding virtual Provides to built packages that follows the PURL (Package-URL) specification. There will likely need to be adaptations and additions to the Packaging Guidelines to account for this change (if approved), so I am required to file a ticket / PR before I publish the Change Proposal.

Current draft: https://fedoraproject.org/wiki/Changes/Adopt_PURL_Metadata

The TL;DR version of what's planned:

Packages for projects that are identifiable by a valid PURL MUST add virtual Provides for this PURL, using the purl(...) "namespace". This should usually happen automatically through updated RPM generator mechanisms that already add virtual Provides in downstream-specific formats like crate(...) or rubygem(...).

This could potentially be extended to bundled(...) Provides, which currently don't use a consistent format at all:

Packages that include bundled dependencies MUST use PURL identifiers for bundled(...) virtual Provides (i.e. bundled(purl(<purl>))) instead of using custom identifiers, where possible.

I'm in the process of submitting a Change proposal that has the goal of adding virtual Provides to built packages that follows the [PURL](https://github.com/package-url/purl-spec) (Package-URL) specification. There will likely need to be adaptations and additions to the Packaging Guidelines to account for this change (if approved), so I am required to file a ticket / PR before I publish the Change Proposal. --- Current draft: https://fedoraproject.org/wiki/Changes/Adopt_PURL_Metadata The TL;DR version of what's planned: > Packages for projects that are identifiable by a valid PURL *MUST* add virtual Provides for this PURL, using the `purl(...)` "namespace". This should usually happen automatically through updated RPM generator mechanisms that already add virtual Provides in downstream-specific formats like `crate(...)` or `rubygem(...)`. This could potentially be extended to `bundled(...)` Provides, which currently don't use a consistent format at all: > Packages that include bundled dependencies *MUST* use PURL identifiers for `bundled(...)` virtual Provides (i.e. `bundled(purl(<purl>))`) instead of using custom identifiers, where possible.

gotmax23 commented

2026-05-14 17:40:02 +00:00

Owner

This was discussed in the meeting today (log) and here is what the AI summary had to say:

The committee discussed the PURL (Package URL) proposal, which aims to standardize dependency metadata to help with security analysis.
A concern was raised that the proposed Provides syntax, purl(pkg:cargo/libc@0.2.186), includes the version in the name, making it unusable for dependency resolution and difficult to query.
An alternative syntax like purl(pkg:cargo/libc) = 0.2.186 was considered, but it faces issues with RPM's version string restrictions (e.g., no dashes), which are common in upstream semantic versioning.
There was a general concern about overloading the Provides mechanism with metadata not used for dependency resolution, as it increases metadata size for all users.

Personally, I very much support this proposal, as I hope it'll help the security bug nightmare, but I think the way versions are handled could use discussion. I don't think changing, e.g., the cargo dependency generator to start depending on the purl(..) Provides instead of craste(..) is part of this proposal, and querying whatprovides purl(pkg:cargo/libc@*) isn't so difficult, but I figured it was worth bringing up.

This was discussed in the meeting today ([log](https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2026-05-14/fpc.2026-05-14-16.00.log.html)) and here is what the AI summary had to say: - The committee discussed the PURL (Package URL) proposal, which aims to standardize dependency metadata to help with security analysis. - A concern was raised that the proposed `Provides` syntax, `purl(pkg:cargo/libc@0.2.186)`, includes the version in the name, making it unusable for dependency resolution and difficult to query. - An alternative syntax like `purl(pkg:cargo/libc) = 0.2.186` was considered, but it faces issues with RPM's version string restrictions (e.g., no dashes), which are common in upstream semantic versioning. - There was a general concern about overloading the `Provides` mechanism with metadata not used for dependency resolution, as it increases metadata size for all users. --- Personally, I very much support this proposal, as I hope it'll help the security bug nightmare, but I think the way versions are handled could use discussion. I don't think changing, e.g., the cargo dependency generator to start depending on the `purl(..)` Provides instead of `craste(..)` is part of this proposal, and querying whatprovides `purl(pkg:cargo/libc@*)` isn't so difficult, but I figured it was worth bringing up.

decathorpe commented

2026-05-14 21:32:06 +00:00

Author

Owner

/me pops in from "vacation" to address some feedback from the meeting:

I have considered using purl(pkg:...) = 0.1.2 format (the "version" part of the PURL is optional, so this would be valid) but ultimately decided against it, exactly for some of the reasons that were mentioned during the meeting (it mixes PURL and RPM syntax, and some upstream version strings are not necessarily uniquely representable as RPM version strings)
I have no plans to remove other virtual Provides in favor of PURL. They are intended to be "Provides" only without there ever being "Requires" for them. I don't think that would even make sense - just because a package indicates that it contains project X doesn't mean that it's in any way usable as an external dependency (similar: you wouldn't use Requires: bundled(foo) if you needed foo, that just wouldn't make any sense.

Also taking a quick look I'm a bit confused about purl(pkg:blah) ... shouldn't it be purl(rpm:blah) ?

No, the URL scheme in PURL is defined as pkg (other URL schemes are "http" or "ftp", replacing it would make it a different URL scheme, but no longer PURL. :)

I think it's supposed to correspond to the upstream package PURL, not the RPM PURL

Yes. Making an RPM provide its own PURL representation would be a bit redundant. That would look like pkg:rpm/fedora/curl@7.50.3-1.fc25?arch=i386&distro=fedora-25 though (copied from the upstream README).

Side note: I'm not sure all these symbols are even allowed in RPM names ... but that might be a bridge that we can postpone crossing.

I don't recall what the Go mod one is which I probably should...

I read tickets in the PURL spec repo, and it looks like there's currently only a "legacy" Go type in the spec that doesn't cover Go modules. It might be nice to propose a new "type" for the spec that covers those. (This is the reason why Go packages aren't listed as initial targets in the Change Proposal doc.)

/me pops in from "vacation" to address some feedback from the meeting: - I have considered using `purl(pkg:...) = 0.1.2` format (the "version" part of the PURL is optional, so this would be *valid*) but ultimately decided against it, exactly for some of the reasons that were mentioned during the meeting (it mixes PURL and RPM syntax, and some upstream version strings are not necessarily uniquely representable as RPM version strings) - I have no plans to remove other virtual Provides in favor of PURL. They are intended to be "Provides" only without there ever being "Requires" for them. I don't think that would even make sense - just because a package indicates that it contains project X doesn't mean that it's in any way *usable* as an external dependency (similar: you wouldn't use `Requires: bundled(foo)` if you needed `foo`, that just wouldn't make any sense. > Also taking a quick look I'm a bit confused about purl(pkg:blah) ... shouldn't it be purl(rpm:blah) ? No, the URL scheme in PURL is defined as `pkg` (other URL schemes are "http" or "ftp", replacing it would make it a *different* URL scheme, but no longer PURL. :) > I think it's supposed to correspond to the upstream package PURL, not the RPM PURL Yes. Making an RPM provide its own PURL representation would be a bit redundant. That would look like `pkg:rpm/fedora/curl@7.50.3-1.fc25?arch=i386&distro=fedora-25` though (copied from the upstream README). Side note: I'm not sure all these symbols are even allowed in RPM names ... but that might be a bridge that we can postpone crossing. > I don't recall what the Go mod one is which I probably should... I read tickets in the PURL spec repo, and it looks like there's currently only a "legacy" Go type in the spec that doesn't cover Go modules. It might be nice to propose a new "type" for the spec that covers those. (This is the reason why Go packages aren't listed as initial targets in the Change Proposal doc.)

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

packaging/guidelines#1536

No description provided.

Rows
Columns