[1/2] create-spdx-3.0: make create_spdx depend on CVE_STATUS

From: Peter Marko <peter.marko@siemens.com>

SPDX3 classes now add CVE_STATUS information to spdx.
So the task needs to be rebuilt when CVE_STATUS changes.

This is true since commit 1ff496546279d8a97df5ec475007cfb095c2a0bc

Signed-off-by: Peter Marko <peter.marko@siemens.com>
cc: Joshua Watt <JPEWhacker@gmail.com>
---
 meta/classes/create-spdx-3.0.bbclass | 1 +
 1 file changed, 1 insertion(+)

On Mon, Mar 31, 2025 at 5:12 AM Peter Marko <peter.marko@siemens.com> wrote:
>
> From: Peter Marko <peter.marko@siemens.com>
>
> SPDX3 classes now add CVE_STATUS information to spdx.
> So the task needs to be rebuilt when CVE_STATUS changes.
>
> This is true since commit 1ff496546279d8a97df5ec475007cfb095c2a0bc
>
> Signed-off-by: Peter Marko <peter.marko@siemens.com>
> cc: Joshua Watt <JPEWhacker@gmail.com>
> ---
>  meta/classes/create-spdx-3.0.bbclass | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/classes/create-spdx-3.0.bbclass b/meta/classes/create-spdx-3.0.bbclass
> index 044517d9f7..235bd804bd 100644
> --- a/meta/classes/create-spdx-3.0.bbclass
> +++ b/meta/classes/create-spdx-3.0.bbclass
> @@ -138,6 +138,7 @@ python do_create_spdx() {
>      oe.spdx30_tasks.create_spdx(d)
>  }
>  do_create_spdx[vardeps] += "\
> +    CVE_STATUS \

Seems fine to me, unless RP thinks we should add cve_check to BBIMPORTS instead?

Reviewed-by: Joshua Watt <JPEWhacker@gmail.com>


>      SPDX_INCLUDE_BITBAKE_PARENT_BUILD \
>      SPDX_PACKAGE_ADDITIONAL_PURPOSE \
>      SPDX_PROFILES \

On Mon, 2025-03-31 at 08:11 -0600, Joshua Watt wrote:
> On Mon, Mar 31, 2025 at 5:12 AM Peter Marko <peter.marko@siemens.com>
> wrote:
> > 
> > From: Peter Marko <peter.marko@siemens.com>
> > 
> > SPDX3 classes now add CVE_STATUS information to spdx.
> > So the task needs to be rebuilt when CVE_STATUS changes.
> > 
> > This is true since commit 1ff496546279d8a97df5ec475007cfb095c2a0bc
> > 
> > Signed-off-by: Peter Marko <peter.marko@siemens.com>
> > cc: Joshua Watt <JPEWhacker@gmail.com>
> > ---
> >  meta/classes/create-spdx-3.0.bbclass | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/meta/classes/create-spdx-3.0.bbclass
> > b/meta/classes/create-spdx-3.0.bbclass
> > index 044517d9f7..235bd804bd 100644
> > --- a/meta/classes/create-spdx-3.0.bbclass
> > +++ b/meta/classes/create-spdx-3.0.bbclass
> > @@ -138,6 +138,7 @@ python do_create_spdx() {
> >      oe.spdx30_tasks.create_spdx(d)
> >  }
> >  do_create_spdx[vardeps] += "\
> > +    CVE_STATUS \
> 
> Seems fine to me, unless RP thinks we should add cve_check to
> BBIMPORTS instead?

That would potentially see off other problems in the future. Is there a
reason we wouldn't want to do that?

Cheers,

Richard

On Mon, Mar 31, 2025 at 8:13 AM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Mon, 2025-03-31 at 08:11 -0600, Joshua Watt wrote:
> > On Mon, Mar 31, 2025 at 5:12 AM Peter Marko <peter.marko@siemens.com>
> > wrote:
> > >
> > > From: Peter Marko <peter.marko@siemens.com>
> > >
> > > SPDX3 classes now add CVE_STATUS information to spdx.
> > > So the task needs to be rebuilt when CVE_STATUS changes.
> > >
> > > This is true since commit 1ff496546279d8a97df5ec475007cfb095c2a0bc
> > >
> > > Signed-off-by: Peter Marko <peter.marko@siemens.com>
> > > cc: Joshua Watt <JPEWhacker@gmail.com>
> > > ---
> > >  meta/classes/create-spdx-3.0.bbclass | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/meta/classes/create-spdx-3.0.bbclass
> > > b/meta/classes/create-spdx-3.0.bbclass
> > > index 044517d9f7..235bd804bd 100644
> > > --- a/meta/classes/create-spdx-3.0.bbclass
> > > +++ b/meta/classes/create-spdx-3.0.bbclass
> > > @@ -138,6 +138,7 @@ python do_create_spdx() {
> > >      oe.spdx30_tasks.create_spdx(d)
> > >  }
> > >  do_create_spdx[vardeps] += "\
> > > +    CVE_STATUS \
> >
> > Seems fine to me, unless RP thinks we should add cve_check to
> > BBIMPORTS instead?
>
> That would potentially see off other problems in the future. Is there a
> reason we wouldn't want to do that?

I can't think of one, as long as it actually works :). I'm testing it
now and I'll send the patch if works

>
> Cheers,
>
> Richard

On Mon, Mar 31, 2025 at 8:15 AM Joshua Watt <jpewhacker@gmail.com> wrote:
>
> On Mon, Mar 31, 2025 at 8:13 AM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > On Mon, 2025-03-31 at 08:11 -0600, Joshua Watt wrote:
> > > On Mon, Mar 31, 2025 at 5:12 AM Peter Marko <peter.marko@siemens.com>
> > > wrote:
> > > >
> > > > From: Peter Marko <peter.marko@siemens.com>
> > > >
> > > > SPDX3 classes now add CVE_STATUS information to spdx.
> > > > So the task needs to be rebuilt when CVE_STATUS changes.
> > > >
> > > > This is true since commit 1ff496546279d8a97df5ec475007cfb095c2a0bc
> > > >
> > > > Signed-off-by: Peter Marko <peter.marko@siemens.com>
> > > > cc: Joshua Watt <JPEWhacker@gmail.com>
> > > > ---
> > > >  meta/classes/create-spdx-3.0.bbclass | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/meta/classes/create-spdx-3.0.bbclass
> > > > b/meta/classes/create-spdx-3.0.bbclass
> > > > index 044517d9f7..235bd804bd 100644
> > > > --- a/meta/classes/create-spdx-3.0.bbclass
> > > > +++ b/meta/classes/create-spdx-3.0.bbclass
> > > > @@ -138,6 +138,7 @@ python do_create_spdx() {
> > > >      oe.spdx30_tasks.create_spdx(d)
> > > >  }
> > > >  do_create_spdx[vardeps] += "\
> > > > +    CVE_STATUS \
> > >
> > > Seems fine to me, unless RP thinks we should add cve_check to
> > > BBIMPORTS instead?
> >
> > That would potentially see off other problems in the future. Is there a
> > reason we wouldn't want to do that?
>
> I can't think of one, as long as it actually works :). I'm testing it
> now and I'll send the patch if works

Just to follow up on this; I think we can fix this more systemically
in bitbake and/or make improvements to make it easier to specify these
types of dependencies in the actual code that references them (see
jpew/var-flag-deps on poky-contrib for some prototypes), so I think it
would be better to take that approach than this one (at least on
master, this is likely better for backport fixes)

>
> >
> > Cheers,
> >
> > Richard