`github` type is ambiguous

[robcresswell]

This is likely my misunderstanding, and apologies if there's a similar issue or discussion that I missed 😃

PURL defines itself as an approach to "reliably identify and locate software packages", yet the github type seems ambiguous; it functions only as a location but not as an identity. These are the examples given for the github type:

pkg:github/package-url/purl-spec@244fd47e07d1004
pkg:github/package-url/purl-spec@244fd47e07d1004#everybody/loves/dogs

My feeling is that it is difficult to adequately identify what software this is. Should github not be captured by other types, as either a namespace (go) or as a repository_url when the GitHub package registry is used?

I realise that one answer might be "just don't use the github type then", but this type of ambiguity undermines the spec itself. I'm keen to learn more about the thinking on this one.

[ChronosMOT]

This is purely my point of few. ^^

I think where another package manager is using github as a source the type specific to that packagemanger should be used. Or in general the most specific type should be used.

But there are many repositories where you can access releases provided directly on github. And in those cases github is the most specific type.

[robcresswell]

@ChronosMOT What do you mean by "there are many repositories where you can access releases provided directly on github"? I guess the example I typically think of is go, where the pURL doesn't mention go at all, which IMO fails the "and identify" part of "A purl is a URL string used to identify and locate a software package". It tells you a software package is in github, but doesn't tell you anything about what it is.

[robcresswell]

Closing; it's been almost 6 months, so I think the spec authors have other priorities than discussing this, which is fine 😇