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

The term "unpackaged" is misleading #233

Open
kzantow opened this issue Dec 26, 2023 · 1 comment
Open

The term "unpackaged" is misleading #233

kzantow opened this issue Dec 26, 2023 · 1 comment

Comments

@kzantow
Copy link
Collaborator

kzantow commented Dec 26, 2023

The library currently outputs "##### Unpackaged files" in Tag Value format when it outputs the files section. However, this is misleading, as the files may be associated with a package using relationships. We should change this comment line to just read "Files".

@swinslow
Copy link
Member

swinslow commented Jan 8, 2024

@kzantow Just to share a bit of context on this (which you may already know!)

This originated with language that's now found in Section 5.2.3 of the SPDX 2.3 spec:

Starting with SPDX 2.0, it is not necessary to have a package wrapping a set of files.
. . .

  • If a file is not part of any package, it shall precede any package information section reference in the SPDX document.

Because of the top-down structure of a tag-value document, with File-inside-Package status being context-dependent based on whether or not the File occurs after a PackageName tag starting the Package section, the "Unpackaged files" comment was meant to signal this status.

You make a good point, though, that a File might not be "in" a Package by virtue of being listed after the Package Info section; but could still be e.g. subject to a CONTAINS Relationship with that Package.

I might question whether that situation would align with the spec's language stating that this is for where "a file is not part of any package".

But either way, the "Unpackaged files" label is just a comment intended to be informative, and I agree that there's no harm at all in removing it here. so I'm +1 to making this change, for what it's worth :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants