create-spdx and sstate

create-spdx and sstate

[Paul Eggleton]

Hi Joshua / all

We've been having an issue with the create-spdx class if we share sstate 
between two configurations - one where gcc-cross-<arch> has a dependency and 
one where it doesn't (specifically, one where the abicheck class in meta-
binaryaudit is inherited and the other where it isn't; that influences 
DEPENDS). The result is that if you build the configuration with the dependency 
then the one where it doesn't (in separate build dirs with the same sstate 
cache), image_combine_spdx fails because it can't find the SPDX data file for 
the dependency as it was not built in the second configuration.

It seems that create-spdx looks at BB_TASKDEPDATA to get dependencies and then 
adds BB_TASKDEPDATA to vardepsexclude, thus the dependencies changing does not 
cause the task to be re-executed. However, I assume a variable dependency on 
BB_TASKDEPDATA might be impractical, thus why it was excluded in the first 
place. Do we instead add an explicit dependency on DEPENDS? I'm happy to come 
up with a patch if we can determine what the correct fix is.

(FWIW we're still using dunfell, but I don't see any changes in master that 
alter this particular behaviour.)

Thanks
Paul

Re: create-spdx and sstate

[Joshua Watt]

On Thu, Jan 5, 2023 at 2:32 PM Paul Eggleton
<bluelightning@bluelightning.org> wrote:
>
> Hi Joshua / all
>
> We've been having an issue with the create-spdx class if we share sstate
> between two configurations - one where gcc-cross-<arch> has a dependency and
> one where it doesn't (specifically, one where the abicheck class in meta-
> binaryaudit is inherited and the other where it isn't; that influences
> DEPENDS). The result is that if you build the configuration with the dependency
> then the one where it doesn't (in separate build dirs with the same sstate
> cache), image_combine_spdx fails because it can't find the SPDX data file for
> the dependency as it was not built in the second configuration.
>
> It seems that create-spdx looks at BB_TASKDEPDATA to get dependencies and then
> adds BB_TASKDEPDATA to vardepsexclude, thus the dependencies changing does not
> cause the task to be re-executed. However, I assume a variable dependency on
> BB_TASKDEPDATA might be impractical, thus why it was excluded in the first
> place. Do we instead add an explicit dependency on DEPENDS? I'm happy to come
> up with a patch if we can determine what the correct fix is.

I think that sounds correct. The class does do_create_spdx[deptask] =
"do_create_spdx" to ensure it picks up all the dependencies from
DEPENDS, it would make sense that it should also have DEPENDS as a
dependent variable so it reruns.

It is a little weird that none of the tasks upstream of do_create_spdx
changing from that class are causing do_create_spdx to be invalidated
and re-run.... but maybe that class is doing something a little less
normal

>
> (FWIW we're still using dunfell, but I don't see any changes in master that
> alter this particular behaviour.)
>
> Thanks
> Paul
>
>