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 - [x] 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 - [x] analysis and testing of possible ways to map debug sources to upstream sources + downstream patches referred to by bitbake recipes