On Thu, Mar 12, 2026 at 5:43 AM Richard Purdie <[email protected]> wrote: > > On Tue, 2026-03-10 at 12:38 -0600, Joshua Watt via lists.openembedded.org > wrote: > > Adds a new package to the SPDX output that represents the recipe data > > for a given recipe. Importantly, this data contains only things that can > > be determined statically from only the recipe, so it doesn't require > > fetching or building anything. This means that build time dependencies > > and CVE information for recipes can be analyzed without needing to > > actually do any builds. > > > > Sadly, license data cannot be included because NO_GENERIC_LICENSE means > > that actual license text might only be available after do_fetch > > We talked about these patches on the review call. I'm a bit worried > about the direction we're going from a few angles. > > The general theme is the complexity and increasingly seemingly tangled > web we seem to be weaving and whether we're going to end up in a good > place. > > Taking NO_GENERIC_LICENSE specifically, it may be we should mandate > that such licenses are copied into the metadata, then we solve the > license data problem that way? That would simplify some of the problems > we're facing and reduce some set of the corner cases. > > This patch adds a new task into the task graph and I'm getting a bit > worried about the number of them the SPDX class is adding. I appreciate > there is a later patch removing one, which is nice though :)
With the removal of the vestigial task in this patch series, the task graph for SPDX is: do_create_recipe_spdx - > "static" information we can determine about the recipe just from the metadata (no fetching, compiling, etc.) do_create_spdx -> Information about what we built and how we built it. We obviously have to build to figure this part out (the definition of this didn't change in this patch series; it should really be called do_create_build_spdx, but it inherited the name from the SPDX 2 code, so I don't want to change it) do_create_runtime_spdx -> Information about runtime packages. This has to be a separate task because while the build graph is a DAG, the runtime graph is not. The definition of this didn't change in this patch series. Various SBoM assembly tasks: These are the tasks that take the individual SPDX files generated by the tasks above and link them into a complete document that ends up in DEPLOY_DIR. They are all identified by having "sbom" in the name (do_create_image_sbom_spdx) > > So, for this patch, could we just drop NO_GENERIC_LICENSE and how much > code complexity improvement does that buy us? I'm not clear what you mean by this. I'm not including any additional License information, because we don't have it. I didn't change any license handling in the SPDX code, and I didn't add any more, so if you're talking about simplifying the SPDX code by dropping NO_GENERIC_LICENSE, it gains you nothing here specifically. It might be nice to improve NO_GENERIC_LICENSE in general, but I don't think we can do that for 6.0. If we do that later, we might be able to add license information to the "recipe" level SPDX data. The comment in the commit messages was probably more of a gripe than useful information (It feels like we _should_ be able to get license data statically, but we can't). I'll just remove it. > > Cheers, > > Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#232968): https://lists.openembedded.org/g/openembedded-core/message/232968 Mute This Topic: https://lists.openembedded.org/mt/118246387/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
