On 11/12/25 16:59, Daniel Wagenknecht wrote: > Hello Fabio, > > thanks for your comments and patch! > > On Mon, 2025-11-10 at 17:13 +0000, Fabio Berton wrote: >> Our first idea was to use 'downloadLocation', but what I understand is >> that this is a package property, and files fetched from the layer are >> 'software_File' type. Looking at the SPDX spec, it appears we could use >> the 'ExternalRef' for this purpose. > > I'm not to familiar with the SPDX spec yet, but adding individual files > entries as `ExternalRef` instead of `downloadLocation` to a recipes > spdx sounds reasonable. > > I think in the long term adding a `SPDXRef-Layer-xyz` entry per layer > with a `downloadLocation` pointing to the subpath of the layer inside a > git repo. I'm not quite shure if it would be possible to formulate a > dependency on a file contained within a different SPDXRef, e.g. > ``` > SPDXRef-Layer-xyz:recipes-core/base-files/base-files/fstab > ``` > or if we'd have to create a SPDXRef Item for each file within a layer > in order to reference it properly. That would make it even more > verbose.
Hi Daniel, Yes, we should have a way to get Git information at parser time to avoid calling for every `file://`. But I don't know exactly how to do this, because if we need to add a variable in all layers, and of course, we can't do this, we still need a fallback if the variable doesn't exist. In my case, we don't use OE-Core from https://git.openembedded.org/, we have all layers in an internal infrastructure, so we need to change all variables to point to our fork. My idea to use functions from 'oe.buildcfg' is to get Git information from the layer and not from variables, it doesn't matter if it's a fork or not. But I didn't cover the case where different remotes are used. I know that when using `repo` to manage Git repositories, it's common to use different remotes, e.g., https://github.com/Freescale/fsl-community-bsp-platform/blob/scarthgap/default.xml. Honestly, I don't know if adding a variable to set the "downloadLocation" will be better or not. > > The approach of having a layer as an independent SPDXRef would mean > getting the git revision etc. for that layer would run only once per > build and not per `file://` entry in SRC_URI. >> >> The idea is to have two options to add this information: one to add the >> full path of a file, and another to add the git information > > IMO the full path to the file is unneeded information, if the file is > solely available locally a `NOASSERTION` would be appropriate. The 'path' option is to not use the 'Git' information, e.g., when using a tarball and not a Git repo. The 'locator' will be '/home/user/src/openembedded-core/meta/recipes-core/busybox/files/syslog' instead of 'git+[https://git.openembedded.org/openembedded-core@ac5d9579a0db63b54bbebb5015de2ae860a462bf#meta/recipes-core/busybox/files/syslog](https://git.openembedded.org/openembedded-core@ac5d9579a0db63b54bbebb5015de2ae860a462bf#meta/recipes-core/busybox/files/syslog)' > >> >> Should I add a variable like 'SPDX_FILE_LOCATION_GIT_REMOTE_<layername> >> = "remote_name"' to set a specific remote for each layer? Would setting >> the git remote be sufficient to cover most cases? > In my experimentation I removed the per-layer setting again because > tracking the `vardeps` for the `do_create_spdx` get's more complicated > with per-layer variables. Uhmm, good point, I didn't think about `vardeps`. >> > Sincerely > Daniel Wagenknecht
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#226491): https://lists.openembedded.org/g/openembedded-core/message/226491 Mute This Topic: https://lists.openembedded.org/mt/116223136/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
