Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SPDX 2->3 conversion of ExternalPackageReferences #81

Closed
Tracked by #74
armintaenzertng opened this issue Feb 22, 2023 · 8 comments
Closed
Tracked by #74

SPDX 2->3 conversion of ExternalPackageReferences #81

armintaenzertng opened this issue Feb 22, 2023 · 8 comments
Assignees
Milestone

Comments

@armintaenzertng
Copy link
Contributor

armintaenzertng commented Feb 22, 2023

This is part of #74:

Edit: updated after I understood that ExternalPackageReference will be split into two new properties. Some references will convert to ExternalIdentifier, others to ExternalReference. See the migration documentation for a conversion guideline.

There remain two problems when the category is OTHER:

  • In this case, type can be String-valued. Should this then be converted to SPDX3 ExternalIdentifierType.other or ExternalReferenceType.other?
  • Also in this case, locator can be an arbitrary String (without spaces) in SPDX2, but the SPDX3 ExternalReference.locator must be a URI. ExternalIdentifier.identifier would be a String, but can we be sure that the SPDX2 reference of category OTHER is actually an identifier?
@armintaenzertng
Copy link
Contributor Author

armintaenzertng commented Apr 5, 2023

The following SPDX 2 external package ref types don't seem to have an SPDX 3 counterpart:

  • url
  • maven-central
  • npm
  • nuget
  • bower

How would they be sorted into identifier vs reference?

@goneall
Copy link
Member

goneall commented Apr 23, 2023

I would suggest - reference.

@kestewart
Copy link
Contributor

This needs to be handled, but not considered a blocker for 3.0-rc

@goneall goneall added this to the 3.0 milestone Jun 3, 2023
@goneall goneall modified the milestones: 3.0, 3.0-rc2 Jul 28, 2023
@goneall
Copy link
Member

goneall commented Jul 28, 2023

Kate and I discussed this. We probably should handle these in RC2 since it will impact the vocabulary.

@goneall
Copy link
Member

goneall commented Jul 29, 2023

@maxhbr - with @armintaenzertng being out, would you mind adding a pull request to add the missing external reference types?

@armintaenzertng
Copy link
Contributor Author

armintaenzertng commented Aug 24, 2023

I opened #484 to address the issue of missing ExternalRefTypes.

However, the initial question of this issue still stands, namely what to do with the OTHER category of SPDX2.
I'd think it would probably be safer to convert these to references instead of identifiers, but as pointed out above, SPDX3 references expect a URI while the OTHER locator is an arbitrary string.

@goneall
Copy link
Member

goneall commented Aug 27, 2023

However, the initial question of this issue still stands, namely what to do with the OTHER category of SPDX2.
I'd think it would probably be safer to convert these to references instead of identifiers, but as pointed out above, SPDX3 identifiers expect a URI while the OTHER locator is an arbitrary string.

I'm thinking we should change the type of ExternalRefTypes to be xsd:string. I'm not sure why we restricted it to a URI if it is a reference.

goneall added a commit that referenced this issue Aug 27, 2023
Partial fix for issue #81

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>
goneall added a commit that referenced this issue Sep 12, 2023
Partial fix for issue #81

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>
@goneall
Copy link
Member

goneall commented Dec 12, 2023

This was resolved with PR #487

@goneall goneall closed this as completed Dec 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants