RPM definition missing qualifiers entries for repository_url and distro

[MoralCode]

Apologies if this is already addressed elsewhere. While working on an implementation, I noticed the RPM docs specify two qualifier fields for determining the repository url (repository_url and distro)

I suspect repository_url is maybe a global field that may be documented elsewhere (i saw the docker type uses this), but distro seems rpm specific.

purl-spec/docs/types/definitions/rpm-definition.md

Line 19 in b5454e7

- **Note:** There is no default package repository, this should be implied either from the distro qualifiers key or using a repository base URL as repository_url qualifiers key.

but the examples table doesnt have entries for either of these

purl-spec/docs/types/definitions/rpm-definition.md

Lines 42 to 45 in b5454e7

	| Key | Requirement | Native name | Default Value | Description |
	|------|-------------|-------------|---------------|-------------|
	| epoch | Optional | | | (optional for RPMs) is a qualifier as its not required for unique identification, but when the epoch exists we strongly encourage using it. |
	| arch | Optional | | | the qualifiers key for a package architecture. |

[yan-foto]

I have also stumbled upon this as I was testing my implementation.

How should an implementation handle qualifiers listed in a type definition? Specifically:

• Is it expected to list all valid qualifiers?
• Should any other key, that is not included, be considered as invalid/prohibited?
• Is there a list of common/general qualifiers that are valid for all types? Is this list normative?
• Should parsers return an error when encountering unlisted qualifier keys?

[mjherzog]

We are actively working on this question this month as part of the prep for ECMA-427 2nd edition. The principles we are working from are:

• An implementation should accept any **qualifiers" that are syntactically correct
• A PURL type definition may include a list (enum) of "registered" qualifiers keys for that type*. If an input PURL contains keys that are not in that type-specific list, an implementation should report a warning message. We do not yet have examples of this behavior in test cases because:
  • Enabling this type of warning message was a key reason for the v0.2 update of the PURL test schema.
  • The change to allow defining "registered" keys for a PURL type is inflight - see:
    • Schema change / purl-type-definition: Add enum for namespace values #690
    • Schema change / purl-type-definition: Add enum for qualifiers keys #710
    • Update purl-type-definition.schema-1.1.json to add registered values for namespace and qualifiers #945
• The list at https://package-url.github.io/www.packageurl.org/docs/purl/common-qualifiers is not currently normative, but we are planning to add some of these to ECMA-427 2nd edition. See also Clarify use of standard qualifiers like repository_url #625
• The key issues in scope for ECMA-427 2nd edition are tracked in the ECMA-427 2nd Edition project. The timeline is that we need to submit the 2nd edition changes to Ecma by early September in order get approval by the Ecma General Assembly in December.

[MoralCode]

So registered/listed qualifiers should be compared when checking if two purl ids are the same?

[matt-phylum]

So registered/listed qualifiers should be compared when checking if two purl ids are the same?

I don't think there's a good answer for this today. For some ecosystems, there are required qualifiers (eg pkg:julia uuid), and it's pretty obvious what to do with those, at least in most cases, but when qualifiers are optional (eg file_name) or when qualifiers have default values (eg repository_url) or when qualifier values need normalization (eg pypi repository_url where the repository moved) or when qualifiers have complex values (eg checksum) or when unknown qualifiers are present it's not really clear what to do in a general algorithm. There might even be different answers depending on for what purpose you're checking for PURL equivalency (eg are pkg:pypi/example@1.0.0?file_name=example-1.0.0.tar.gz and pkg:pypi/example@1.0.0?file_name=example-1.0.0-py3-none-any.whl the same package?).