Generic qualifier for package source URL

[behrisch]

I am still quite new to purl and think it is a great effort. But after reading some of the docs I am still wondering if there is a generic way of specifying the sources which have been used to build a package. I understood that the download_url qualifier is probably not the right way and I also read the discussion about debian sources here. Especially these comments already mentioned a related problem namely how to tag a package as a source package independent of the type. Is there already a universally adopted approach or proposal concerning this? I see three different approaches in the docs:

1. arch=source as used in the final solution for debian
2. packaging=sources as mentioned here
3. classifier=sources as seen here

All of them only cover the case of flagging a package as source but not of linking a (possibly binary) package to its sources. So my questions are: Is the latter case a general useful addition to a purl or not? Should I rather give two purls if I want to document binary and source? Is one of the three schemes above going to be adopted for more than one type (currently the first one seems to be only mentioned for debian and the two others for maven).

[ppkarwasz]

Linking a package to its source archive is out of scope for Package URL. That relationship is better handled by SBOMs—see CycloneDX/specification#648.

Your question is valid: how should a PURL refer to a source archive? In Debian, arch=source refers to buildable source packages. But in Java, sources JARs only offer partial source code—missing build configs and generated files—so they aren't equivalent.

Using generic PURLs for source archives (e.g., from apache.org or curl.se) is possible, but risky due to lack of a namespace. That can lead to confusion or even deliberate name collisions. swid might help, but the spec is behind a paywall and I am not familiar with it.

[gernot-h]

I definitely would welcome a general approach for identifying sources, I'm however not sure if all ecosystems supported by PURL have a defined and clear workflow on how to get to a certain source code bundle. At least I've seen colleagues implementing things like Github "tag guessing" for given scripting language packages. So this could lead to having certain classes of source PURLs which we can't resolve to a certain package automatically. On the other hand, we anyways already have a certain share of (binary) PURLs in real world examples we can't resolve, e.g. from self-build packages or 3rd party packages where the scanner didn't correctly detect they're not from the main repositories.

That said, I so far preferred to add source references per PURL type, there's also a somehow stuck PR regarding Alpine sources: #312.