Punch List: Package

[iamwillbar]

This is a punch list of open questions from the 2021-12-07 Tech Team meeting. Please comment on this issue with any discussion, proposed answers, or additional questions you have:

• Review 2.2 Package and make sure not dropping use cases?
• Should download location be considered as an external reference?
• Should homepage be considered as an external reference or a property?
• Is package-file-name a relationship or a property?
• Is supplier a relationship? (note define some new relationships)
• Is files-analyzed replaced by profiles?

[iamwillbar]

@kestewart to think about package-file-name as relationship.

[seabass-labrax]

A package doesn't have a file name, because what Package describes is not a file. Package describes a collection of files and the interactions that they have with other entities in aggregate.

Once what a Package represents have been assembled into an archive, it is that archive which is a singular file (or some independent files, in some edge cases. Think ten floppies for a single software installation 😃). It is thus the archive which is described with a File element and has a file name property.

For example, a package libcbor-v0.9.0 is a just a collection of files with file names relative to each other, but there is also a downloadable archive called v0.9.0.tar.gz which corresponds to that package. Only the archive of libcbor-v0.9.0 has a file name.

In conclusion, my preference would be to omit a file name property on Package.

[iamwillbar]

@seabass-labrax that's my preference as well for the same reasoning, @kestewart raised the concern so let's wait for her feedback before closing this item.

[goneall]

Is package-file-name a relationship or a property?

From the discussion on the 15 April extended tech call, there was general consensus that this should be a relationship. This provides additional information and is a more accurate representation of how the package is used.

There does, however, create some additional complexity by requiring a relationship and isn't compatible with 2.X where it is just a string property + a hash property. On the call we discussed a need to provide good documentation on how to use relationships for the package file to at least partially address the complexity concern.

[goneall]

On the 15 April extended tech call we discussed a couple of different use cases for the package file where the file may be located in multiple location or the actual destination of the package file isn't know.

I would propose adding a couple of new relationships to help cover these use cases:

• DISTRIBUTED_TO the file location the originator of the package distributes the package file to. For example - when building an ISO image, DISTRIBUTED_TO can be used to describe the location on the ISO image where the package file was copied. Note that in this example, the ISO file will likely also have a CONTAINS relationship to the same file.
• DEPLOYED_TO the file location the file is copied to in the final installation. In the ISO example, this would be the location on disk the file is copied to after the installation from the ISO is complete.

[kestewart]

@iamwillbar - am closing this issue as all the topics in the punch list have been discussed. Please reopen if you disagree.