On Thu, 2026-03-12 at 08:11 -0600, Joshua Watt wrote: > 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.
I'm not entirely sure why we couldn't collect both sets of information in one go in the same task, maybe inspecting BB_TASKDEPS instead of the tasks actual dependencies but that is getting distracted into other issues I guess. > 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. Ok, fair enough. I was more thinking that we could fix things so we could get that information. I think I was getting confused and thinking you were getting partial information. We should perhaps separate out the NO_GENERIC_LICENSE issue into a separate bug/issue to work on. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#232998): https://lists.openembedded.org/g/openembedded-core/message/232998 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]] -=-=-=-=-=-=-=-=-=-=-=-
