Technical Team/Minutes/2016-04-05

From SPDX Wiki
< Technical Team‎ | Minutes
Revision as of 18:04, 26 April 2016 by Goneall (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

April 5, 2016


  • Gary O'Neall
  • Hasib Khanafer
  • Bill Schineller
  • Kirstin Newcomer
  • Mark Gisi
  • Jack Manbeck
  • Yev Bronshteyn
  • Scott Sterling

Update from Collaboration Summit Summit

  • 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)
  • 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