THE SPDX WIKI IS NO LONGER ACTIVE. ALL CONTENT HAS BEEN MOVED TO https://github.com/spdx
Technical Team/Minutes/2016-04-05
From SPDX Wiki
< Technical Team | Minutes
April 5, 2016
Attendees
- Gary O'Neall
- Hasib Khanafer
- Bill Schineller
- Kirstin Newcomer
- Mark Gisi
- Jack Manbeck
- Yev Bronshteyn
- Scott Sterling
Update from Collaboration Summit Summit
https://docs.google.com/document/d/1hU1PTTMKWtDaerr3RA56SvvpA74LUd0djHgUhz6Nr9E/edit
- Discussion on requirement to have a package in every SPDX document
- Has been an assumption in the past
- Cardinality - Package
- Correction use case - just refer to another SPDX document that has the package and make a correction
- Need a describes relationship
- Currently not specified
- Can be implemented in the 2.1 spec
- use a describes relationship with a document - only requires an SPDX element, could be a file or any item. If a package is not present, the describes relationship must be specified. Need to update the example in describes.
- Already supported according to top level section 3
- Discussion on the cardinality of the packageVerificationCode being dependent on the has files field
- Cannot use the OWL constraint
- Discussed possibly requiring the verification code but changing the algorithm
- Possible algorithm is to use blank SHA1 if no files
- Agree that the spec will take precedence and the constraints will need to be programmed into the tools for RDF (no change to spec)
- Discussion on external IDs
- Debian is still open - generic proposal (does not include the distro version)
- Problem that the current Debian spec is not entirely unique - need the distro version to make it precise
- Even with the problem, it is likely good enough - there are other mechanisms to make sure the package is unique (package verification code, download location, checksum)
- Debian is still open - generic proposal (does not include the distro version)
- Target date - Plugfest at Linux Con in August - Target spec June completion
- Discuss CPE use case of a preliminary CPE - should it be a query of a pre-existing ID?
- Desire for it to be an ID - semantics
- Could be used as a query based on the spec today
- Concern that not having the ID specified may be missleading
- Resolve as a best practice
- Request to follow-up with Robin on the use case