Analysis of create-spdx bbclass and of possible methods of deps reconstructions

Diary of R&D work on create-spdx bbclass to reuse its output to create a dependency graph

The information we need to extract is basically, in human-readable terms:

Image MyImage.wic CONTAINS binary file /usr/bin/foo 
  GENERATED_FROM src/foo.c, src/foo.h
    CONTAINED_BY source package foo-0.0.1.tgz
      FETCHED_BY bbrecipe foo-0.0.1-r0
  DEPENDS_ON binary file /usr/lib/libfoo, /usr/lib/libfoooo

by cross-leveraging such information with information coming from fossology, we may conclude, in human-readable terms:

• Fossology tells that src/foo.c, src/foo.h are licensed under GPL-2.0-only, so /usr/bin/foo is licensed under GPL-2.0-only

• Libfoooo is licensed under Apache-2.0 so we have a license incompatibility issue

Work plan

• analysis of create-spdx bbclass and related classes and functions
  • outcome: it is not necessary to use create-spdx bbclass and parse its output (overkill), it is much easier to leverage some of the openembedded and bitbake functions it uses to get the same results in a much simpler way
  • main issue: bitbake provides mapping of debug sources to binaries, for debugging purposes; debug sources are copied to workdirs, patched and configured, and they need to be mapped to actual upstream sources and downstream patches referred to by bitbake recipes; however, some functions available in openembedded and bitbake may help a lot
• analysis and testing of possible ways to map debug sources to upstream sources + downstream patches referred to by bitbake recipes