[PATCH] sstate/sstatesig: Abstract dummy package architectures into layer.conf settings

[PATCH] sstate/sstatesig: Abstract dummy package architectures into layer.conf settings

[Richard Purdie]

Other layers need to be able to add dummy recipes. To do this add
DUMMY_PACKAGE_ARCHS_SDK and DUMMY_PACKAGE_ARCHS_TARGET in layer.conf
which can be used to add these to the right places in the code.

Don't add the variables to task signatures as these only matter in the
context of constructed images and not the recipes.

d-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 meta/classes-global/sstate.bbclass | 7 +++----
 meta/conf/layer.conf               | 3 +++
 meta/lib/oe/sstatesig.py           | 9 +++------
 3 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/meta/classes-global/sstate.bbclass b/meta/classes-global/sstate.bbclass
index a7c3f5332a2..fe70a976869 100644
--- a/meta/classes-global/sstate.bbclass
+++ b/meta/classes-global/sstate.bbclass
@@ -86,14 +86,13 @@ SSTATE_ARCHS = " \
     ${BUILD_ARCH}_${ORIGNATIVELSBSTRING} \
     ${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS} \
     ${SDK_ARCH}-${SDKPKGSUFFIX} \
-    buildtools-dummy-${SDKPKGSUFFIX} \
-    sdk-provides-dummy-target \
-    sdk-provides-dummy-${SDKPKGSUFFIX} \
+    ${DUMMY_PACKAGE_ARCHS_SDK} \
+    ${DUMMY_PACKAGE_ARCHS_TARGET} \
     allarch \
     ${SSTATE_ARCHS_TUNEPKG} \
     ${PACKAGE_EXTRA_ARCHS} \
     ${MACHINE_ARCH}"
-SSTATE_ARCHS[vardepsexclude] = "ORIGNATIVELSBSTRING"
+SSTATE_ARCHS[vardepsexclude] = "ORIGNATIVELSBSTRING DUMMY_PACKAGE_ARCHS_SDK DUMMY_PACKAGE_ARCHS_TARGET"
 
 SSTATECREATEFUNCS += "sstate_hardcode_path"
 SSTATECREATEFUNCS[vardeps] = "SSTATE_SCAN_FILES"
diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index ba25ca30296..4794e660aed 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -133,6 +133,9 @@ SSTATE_EXCLUDEDEPS_SYSROOT += "\
 # dependency in the recipe.
 SSTATE_EXCLUDEDEPS_SYSROOT += ".*->autoconf-archive-native"
 
+DUMMY_PACKAGE_ARCHS_SDK = "buildtools-dummy-${SDKPKGSUFFIX} sdk-provides-dummy-${SDKPKGSUFFIX}"
+DUMMY_PACKAGE_ARCHS_TARGET = "sdk-provides-dummy-target"
+
 # We need to keep bitbake tools in PATH
 # Avoid empty path entries
 BITBAKEPATH := "${@os.path.dirname(bb.utils.which(d.getVar('PATH'),'bitbake'))}"
diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index 86d159ed209..cae12eb8781 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -494,7 +494,7 @@ def sstate_get_manifest_filename(task, d):
         d2.setVar("SSTATE_PKGARCH", extrainf)
     return (d2.expand("${SSTATE_MANFILEPREFIX}.%s" % task), d2)
 
-@bb.parse.vardepsexclude("BBEXTENDCURR", "BBEXTENDVARIANT", "OVERRIDES", "PACKAGE_EXTRA_ARCHS")
+@bb.parse.vardepsexclude("BBEXTENDCURR", "BBEXTENDVARIANT", "OVERRIDES", "PACKAGE_EXTRA_ARCHS", "DUMMY_PACKAGE_ARCHS_SDK", "DUMMY_PACKAGE_ARCHS_TARGET")
 def find_sstate_manifest(taskdata, taskdata2, taskname, d, multilibcache):
     d2 = d
     variant = ''
@@ -513,10 +513,7 @@ def find_sstate_manifest(taskdata, taskdata2, taskname, d, multilibcache):
     if taskdata.endswith("-native"):
         pkgarchs = ["${BUILD_ARCH}", "${BUILD_ARCH}_${ORIGNATIVELSBSTRING}"]
     elif taskdata.startswith("nativesdk-") or "-cross-canadian" in taskdata:
-        pkgarchs = ["${SDK_ARCH}-${SDKPKGSUFFIX}",
-                    "allarch",
-                    "buildtools-dummy-${SDKPKGSUFFIX}",
-                    "sdk-provides-dummy-${SDKPKGSUFFIX}"]
+        pkgarchs = ["${SDK_ARCH}-${SDKPKGSUFFIX}", "allarch", (d.getVar("DUMMY_PACKAGE_ARCHS_SDK") or "").split()]
     elif "-cross-" in taskdata:
         pkgarchs = ["${BUILD_ARCH}"]
     elif "-crosssdk" in taskdata:
@@ -525,7 +522,7 @@ def find_sstate_manifest(taskdata, taskdata2, taskname, d, multilibcache):
         pkgarchs = ['${MACHINE_ARCH}']
         pkgarchs = pkgarchs + list(reversed(d2.getVar("PACKAGE_EXTRA_ARCHS").split()))
         pkgarchs.append('allarch')
-        pkgarchs.append('sdk-provides-dummy-target')
+        pkgarchs.extend((d.getVar("DUMMY_PACKAGE_ARCHS_TARGET") or "").split() )
         pkgarchs.append('${SDK_ARCH}-${SDKPKGSUFFIX}')
 
     searched_manifests = []

Patchtest results for [PATCH] sstate/sstatesig: Abstract dummy package architectures into layer.conf settings

[patchtest]

[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]

Thank you for your submission. Patchtest identified one
or more issues with the patch. Please see the log below for
more information:

---
Testing patch /home/patchtest/share/mboxes/sstate-sstatesig-Abstract-dummy-package-architectures-into-layer.conf-settings.patch

FAIL: test Signed-off-by presence: Mbox is missing Signed-off-by. Add it manually or with "git commit --amend -s" (test_mbox.TestMbox.test_signed_off_by_presence)

PASS: pretest pylint (test_python_pylint.PyLint.pretest_pylint)
PASS: test author valid (test_mbox.TestMbox.test_author_valid)
PASS: test commit message presence (test_mbox.TestMbox.test_commit_message_presence)
PASS: test commit message user tags (test_mbox.TestMbox.test_commit_message_user_tags)
PASS: test mbox format (test_mbox.TestMbox.test_mbox_format)
PASS: test non-AUH upgrade (test_mbox.TestMbox.test_non_auh_upgrade)
PASS: test pylint (test_python_pylint.PyLint.test_pylint)
PASS: test shortlog format (test_mbox.TestMbox.test_shortlog_format)
PASS: test shortlog length (test_mbox.TestMbox.test_shortlog_length)
PASS: test target mailing list (test_mbox.TestMbox.test_target_mailing_list)

SKIP: test CVE tag format: No new CVE patches introduced (test_patch.TestPatch.test_cve_tag_format)
SKIP: test Signed-off-by presence: No new CVE patches introduced (test_patch.TestPatch.test_signed_off_by_presence)
SKIP: test Upstream-Status presence: No new CVE patches introduced (test_patch.TestPatch.test_upstream_status_presence_format)
SKIP: test bugzilla entry format: No bug ID found (test_mbox.TestMbox.test_bugzilla_entry_format)
SKIP: test series merge on head: Merge test is disabled for now (test_mbox.TestMbox.test_series_merge_on_head)

---

Please address the issues identified and
submit a new revision of the patch, or alternatively, reply to this
email with an explanation of why the patch should be accepted. If you
believe these results are due to an error in patchtest, please submit a
bug at https://bugzilla.yoctoproject.org/ (use the 'Patchtest' category
under 'Yocto Project Subprojects'). For more information on specific
failures, see: https://wiki.yoctoproject.org/wiki/Patchtest. Thank
you!

RE: [OE-core] [PATCH] sstate/sstatesig: Abstract dummy package architectures into layer.conf settings

[Peter Kjellerstedt]

> -----Original Message-----
> From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org> On Behalf Of Richard Purdie via lists.openembedded.org
> Sent: den 14 mars 2026 11:27
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] sstate/sstatesig: Abstract dummy package architectures into layer.conf settings
> 
> Other layers need to be able to add dummy recipes. To do this add
> DUMMY_PACKAGE_ARCHS_SDK and DUMMY_PACKAGE_ARCHS_TARGET in layer.conf
> which can be used to add these to the right places in the code.
> 
> Don't add the variables to task signatures as these only matter in the
> context of constructed images and not the recipes.
> 
> d-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  meta/classes-global/sstate.bbclass | 7 +++----
>  meta/conf/layer.conf               | 3 +++
>  meta/lib/oe/sstatesig.py           | 9 +++------
>  3 files changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/meta/classes-global/sstate.bbclass b/meta/classes-global/sstate.bbclass
> index a7c3f5332a2..fe70a976869 100644
> --- a/meta/classes-global/sstate.bbclass
> +++ b/meta/classes-global/sstate.bbclass
> @@ -86,14 +86,13 @@ SSTATE_ARCHS = " \
>      ${BUILD_ARCH}_${ORIGNATIVELSBSTRING} \
>      ${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS} \
>      ${SDK_ARCH}-${SDKPKGSUFFIX} \
> -    buildtools-dummy-${SDKPKGSUFFIX} \
> -    sdk-provides-dummy-target \
> -    sdk-provides-dummy-${SDKPKGSUFFIX} \
> +    ${DUMMY_PACKAGE_ARCHS_SDK} \
> +    ${DUMMY_PACKAGE_ARCHS_TARGET} \
>      allarch \
>      ${SSTATE_ARCHS_TUNEPKG} \
>      ${PACKAGE_EXTRA_ARCHS} \
>      ${MACHINE_ARCH}"
> -SSTATE_ARCHS[vardepsexclude] = "ORIGNATIVELSBSTRING"
> +SSTATE_ARCHS[vardepsexclude] = "ORIGNATIVELSBSTRING DUMMY_PACKAGE_ARCHS_SDK DUMMY_PACKAGE_ARCHS_TARGET"
> 
>  SSTATECREATEFUNCS += "sstate_hardcode_path"
>  SSTATECREATEFUNCS[vardeps] = "SSTATE_SCAN_FILES"
> diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
> index ba25ca30296..4794e660aed 100644
> --- a/meta/conf/layer.conf
> +++ b/meta/conf/layer.conf
> @@ -133,6 +133,9 @@ SSTATE_EXCLUDEDEPS_SYSROOT += "\
>  # dependency in the recipe.
>  SSTATE_EXCLUDEDEPS_SYSROOT += ".*->autoconf-archive-native"
> 
> +DUMMY_PACKAGE_ARCHS_SDK = "buildtools-dummy-${SDKPKGSUFFIX} sdk-provides-dummy-${SDKPKGSUFFIX}"
> +DUMMY_PACKAGE_ARCHS_TARGET = "sdk-provides-dummy-target"

Wouldn't it be more appropriate to use += for these two?
Otherwise one will have to use :append to add to them in other layers.

> +
>  # We need to keep bitbake tools in PATH
>  # Avoid empty path entries
>  BITBAKEPATH := "${@os.path.dirname(bb.utils.which(d.getVar('PATH'),'bitbake'))}"
> diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
> index 86d159ed209..cae12eb8781 100644
> --- a/meta/lib/oe/sstatesig.py
> +++ b/meta/lib/oe/sstatesig.py
> @@ -494,7 +494,7 @@ def sstate_get_manifest_filename(task, d):
>          d2.setVar("SSTATE_PKGARCH", extrainf)
>      return (d2.expand("${SSTATE_MANFILEPREFIX}.%s" % task), d2)
> 
> -@bb.parse.vardepsexclude("BBEXTENDCURR", "BBEXTENDVARIANT", "OVERRIDES", "PACKAGE_EXTRA_ARCHS")
> +@bb.parse.vardepsexclude("BBEXTENDCURR", "BBEXTENDVARIANT", "OVERRIDES", "PACKAGE_EXTRA_ARCHS", "DUMMY_PACKAGE_ARCHS_SDK", "DUMMY_PACKAGE_ARCHS_TARGET")
>  def find_sstate_manifest(taskdata, taskdata2, taskname, d, multilibcache):
>      d2 = d
>      variant = ''
> @@ -513,10 +513,7 @@ def find_sstate_manifest(taskdata, taskdata2, taskname, d, multilibcache):
>      if taskdata.endswith("-native"):
>          pkgarchs = ["${BUILD_ARCH}", "${BUILD_ARCH}_${ORIGNATIVELSBSTRING}"]
>      elif taskdata.startswith("nativesdk-") or "-cross-canadian" in taskdata:
> -        pkgarchs = ["${SDK_ARCH}-${SDKPKGSUFFIX}",
> -                    "allarch",
> -                    "buildtools-dummy-${SDKPKGSUFFIX}",
> -                    "sdk-provides-dummy-${SDKPKGSUFFIX}"]
> +        pkgarchs = ["${SDK_ARCH}-${SDKPKGSUFFIX}", "allarch", (d.getVar("DUMMY_PACKAGE_ARCHS_SDK") or "").split()]
>      elif "-cross-" in taskdata:
>          pkgarchs = ["${BUILD_ARCH}"]
>      elif "-crosssdk" in taskdata:
> @@ -525,7 +522,7 @@ def find_sstate_manifest(taskdata, taskdata2, taskname, d, multilibcache):
>          pkgarchs = ['${MACHINE_ARCH}']
>          pkgarchs = pkgarchs + list(reversed(d2.getVar("PACKAGE_EXTRA_ARCHS").split()))
>          pkgarchs.append('allarch')
> -        pkgarchs.append('sdk-provides-dummy-target')
> +        pkgarchs.extend((d.getVar("DUMMY_PACKAGE_ARCHS_TARGET") or "").split() )
>          pkgarchs.append('${SDK_ARCH}-${SDKPKGSUFFIX}')
> 
>      searched_manifests = []

//Peter

Re: [OE-core] [PATCH] sstate/sstatesig: Abstract dummy package architectures into layer.conf settings

[Richard Purdie]

On Mon, 2026-03-16 at 11:21 +0000, Peter Kjellerstedt wrote:
> > -----Original Message-----
> > From:
> > openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org
> > > On Behalf Of Richard Purdie via lists.openembedded.org
> > Sent: den 14 mars 2026 11:27
> > To: openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH] sstate/sstatesig: Abstract dummy package
> > architectures into layer.conf settings
> > 
> > Other layers need to be able to add dummy recipes. To do this add
> > DUMMY_PACKAGE_ARCHS_SDK and DUMMY_PACKAGE_ARCHS_TARGET in
> > layer.conf
> > which can be used to add these to the right places in the code.
> > 
> > Don't add the variables to task signatures as these only matter in
> > the
> > context of constructed images and not the recipes.
> > 
> > d-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > ---
> >  meta/classes-global/sstate.bbclass | 7 +++----
> >  meta/conf/layer.conf               | 3 +++
> >  meta/lib/oe/sstatesig.py           | 9 +++------
> >  3 files changed, 9 insertions(+), 10 deletions(-)
> > 
> > diff --git a/meta/classes-global/sstate.bbclass b/meta/classes-
> > global/sstate.bbclass
> > index a7c3f5332a2..fe70a976869 100644
> > --- a/meta/classes-global/sstate.bbclass
> > +++ b/meta/classes-global/sstate.bbclass
> > @@ -86,14 +86,13 @@ SSTATE_ARCHS = " \
> >      ${BUILD_ARCH}_${ORIGNATIVELSBSTRING} \
> >      ${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS} \
> >      ${SDK_ARCH}-${SDKPKGSUFFIX} \
> > -    buildtools-dummy-${SDKPKGSUFFIX} \
> > -    sdk-provides-dummy-target \
> > -    sdk-provides-dummy-${SDKPKGSUFFIX} \
> > +    ${DUMMY_PACKAGE_ARCHS_SDK} \
> > +    ${DUMMY_PACKAGE_ARCHS_TARGET} \
> >      allarch \
> >      ${SSTATE_ARCHS_TUNEPKG} \
> >      ${PACKAGE_EXTRA_ARCHS} \
> >      ${MACHINE_ARCH}"
> > -SSTATE_ARCHS[vardepsexclude] = "ORIGNATIVELSBSTRING"
> > +SSTATE_ARCHS[vardepsexclude] = "ORIGNATIVELSBSTRING
> > DUMMY_PACKAGE_ARCHS_SDK DUMMY_PACKAGE_ARCHS_TARGET"
> > 
> >  SSTATECREATEFUNCS += "sstate_hardcode_path"
> >  SSTATECREATEFUNCS[vardeps] = "SSTATE_SCAN_FILES"
> > diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
> > index ba25ca30296..4794e660aed 100644
> > --- a/meta/conf/layer.conf
> > +++ b/meta/conf/layer.conf
> > @@ -133,6 +133,9 @@ SSTATE_EXCLUDEDEPS_SYSROOT += "\
> >  # dependency in the recipe.
> >  SSTATE_EXCLUDEDEPS_SYSROOT += ".*->autoconf-archive-native"
> > 
> > +DUMMY_PACKAGE_ARCHS_SDK = "buildtools-dummy-${SDKPKGSUFFIX} sdk-
> > provides-dummy-${SDKPKGSUFFIX}"
> > +DUMMY_PACKAGE_ARCHS_TARGET = "sdk-provides-dummy-target"
> 
> Wouldn't it be more appropriate to use += for these two?
> Otherwise one will have to use :append to add to them in other
> layers.

That depends on whether your layer is included after core or not. I'd
have thought including before core would be potentially problematic
anyway...

Cheers,

Richard

RE: [OE-core] [PATCH] sstate/sstatesig: Abstract dummy package architectures into layer.conf settings

[Peter Kjellerstedt]

> -----Original Message-----
> From: Richard Purdie <richard.purdie@linuxfoundation.org>
> Sent: den 16 mars 2026 12:29
> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] sstate/sstatesig: Abstract dummy package architectures into layer.conf settings
> 
> On Mon, 2026-03-16 at 11:21 +0000, Peter Kjellerstedt wrote:
> > > -----Original Message-----
> > > From: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org On Behalf Of Richard Purdie via lists.openembedded.org
> > > Sent: den 14 mars 2026 11:27
> > > To: openembedded-core@lists.openembedded.org
> > > Subject: [OE-core] [PATCH] sstate/sstatesig: Abstract dummy package
> > > architectures into layer.conf settings
> > >
> > > Other layers need to be able to add dummy recipes. To do this add
> > > DUMMY_PACKAGE_ARCHS_SDK and DUMMY_PACKAGE_ARCHS_TARGET in layer.conf
> > > which can be used to add these to the right places in the code.
> > >
> > > Don't add the variables to task signatures as these only matter in the
> > > context of constructed images and not the recipes.
> > >
> > > d-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > > ---
> > >  meta/classes-global/sstate.bbclass | 7 +++----
> > >  meta/conf/layer.conf               | 3 +++
> > >  meta/lib/oe/sstatesig.py           | 9 +++------
> > >  3 files changed, 9 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/meta/classes-global/sstate.bbclass b/meta/classes-global/sstate.bbclass
> > > index a7c3f5332a2..fe70a976869 100644
> > > --- a/meta/classes-global/sstate.bbclass
> > > +++ b/meta/classes-global/sstate.bbclass
> > > @@ -86,14 +86,13 @@ SSTATE_ARCHS = " \
> > >      ${BUILD_ARCH}_${ORIGNATIVELSBSTRING} \
> > >      ${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS} \
> > >      ${SDK_ARCH}-${SDKPKGSUFFIX} \
> > > -    buildtools-dummy-${SDKPKGSUFFIX} \
> > > -    sdk-provides-dummy-target \
> > > -    sdk-provides-dummy-${SDKPKGSUFFIX} \
> > > +    ${DUMMY_PACKAGE_ARCHS_SDK} \
> > > +    ${DUMMY_PACKAGE_ARCHS_TARGET} \
> > >      allarch \
> > >      ${SSTATE_ARCHS_TUNEPKG} \
> > >      ${PACKAGE_EXTRA_ARCHS} \
> > >      ${MACHINE_ARCH}"
> > > -SSTATE_ARCHS[vardepsexclude] = "ORIGNATIVELSBSTRING"
> > > +SSTATE_ARCHS[vardepsexclude] = "ORIGNATIVELSBSTRING DUMMY_PACKAGE_ARCHS_SDK DUMMY_PACKAGE_ARCHS_TARGET"
> > >
> > >  SSTATECREATEFUNCS += "sstate_hardcode_path"
> > >  SSTATECREATEFUNCS[vardeps] = "SSTATE_SCAN_FILES"
> > > diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
> > > index ba25ca30296..4794e660aed 100644
> > > --- a/meta/conf/layer.conf
> > > +++ b/meta/conf/layer.conf
> > > @@ -133,6 +133,9 @@ SSTATE_EXCLUDEDEPS_SYSROOT += "\
> > >  # dependency in the recipe.
> > >  SSTATE_EXCLUDEDEPS_SYSROOT += ".*->autoconf-archive-native"
> > >
> > > +DUMMY_PACKAGE_ARCHS_SDK = "buildtools-dummy-${SDKPKGSUFFIX} sdk-provides-dummy-${SDKPKGSUFFIX}"
> > > +DUMMY_PACKAGE_ARCHS_TARGET = "sdk-provides-dummy-target"
> >
> > Wouldn't it be more appropriate to use += for these two?
> > Otherwise one will have to use :append to add to them in other
> > layers.
> 
> That depends on whether your layer is included after core or not. I'd
> have thought including before core would be potentially problematic
> anyway...

Sure, but with += the order does not matter.

> 
> Cheers,
> 
> Richard

We have "meta" as the last layer in BBLAYERS in our setup. E.g., 
these are the external layers I have in one of our configurations:

BBLAYERS ?= " \
  ...
  .../meta-virtualization \
  .../meta-webserver \
  .../meta-multimedia \
  .../meta-filesystems \
  .../meta-networking \
  .../meta-python \
  .../meta-oe \
  .../meta-poky \
  .../meta \
"

We have them configured like this to as best as possible match the 
layer priorities. It is not perfect (e.g., meta-poky prepends to 
BBPATH instead of appending like all the other layers do), but it 
has resulted in the least surprises regarding things that are based 
on BBPATH and things that are based on layer priorities.

//Peter

Re: [OE-core] [PATCH] sstate/sstatesig: Abstract dummy package architectures into layer.conf settings

[Richard Purdie]

On Mon, 2026-03-16 at 13:03 +0000, Peter Kjellerstedt wrote:
> > > Wouldn't it be more appropriate to use += for these two?
> > > Otherwise one will have to use :append to add to them in other
> > > layers.
> > 
> > That depends on whether your layer is included after core or not.
> > I'd have thought including before core would be potentially
> > problematic anyway...
> 
> Sure, but with += the order does not matter.
> 
> We have "meta" as the last layer in BBLAYERS in our setup. E.g., 
> these are the external layers I have in one of our configurations:
> 
> BBLAYERS ?= " \
>   ...
>   .../meta-virtualization \
>   .../meta-webserver \
>   .../meta-multimedia \
>   .../meta-filesystems \
>   .../meta-networking \
>   .../meta-python \
>   .../meta-oe \
>   .../meta-poky \
>   .../meta \
> "
> 
> We have them configured like this to as best as possible match the 
> layer priorities. It is not perfect (e.g., meta-poky prepends to 
> BBPATH instead of appending like all the other layers do), but it 
> has resulted in the least surprises regarding things that are based 
> on BBPATH and things that are based on layer priorities.

We need to rewrite how this all works and remove some of the options as
it is all too complex and everyone is putting it together differently
and hoping for the best :(.

Trying to "support" the number of possible combinations that people
might put things together is problematic. The ask is that everything
works regardless of how you configure it and nobody even
understands/agrees on the basic rules.

If you don't understand my concern, think about how you'd recreate that
setup just starting from core and using bitbake-layers add-layer. I
don't think you can.

It is too late to do anything about it right now and I've put off
trying to improve things as I know the shear amount of complaints I'll
get but there is a problem here.

Cheers,

Richard

RE: [OE-core] [PATCH] sstate/sstatesig: Abstract dummy package architectures into layer.conf settings

[Peter Kjellerstedt]

> -----Original Message-----
> From: Richard Purdie <richard.purdie@linuxfoundation.org>
> Sent: den 17 mars 2026 09:22
> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] sstate/sstatesig: Abstract dummy package architectures into layer.conf settings
> 
> On Mon, 2026-03-16 at 13:03 +0000, Peter Kjellerstedt wrote:
> > > > Wouldn't it be more appropriate to use += for these two?
> > > > Otherwise one will have to use :append to add to them in other
> > > > layers.
> > >
> > > That depends on whether your layer is included after core or not.
> > > I'd have thought including before core would be potentially
> > > problematic anyway...
> >
> > Sure, but with += the order does not matter.
> >
> > We have "meta" as the last layer in BBLAYERS in our setup. E.g.,
> > these are the external layers I have in one of our configurations:
> >
> > BBLAYERS ?= " \
> >   ...
> >   .../meta-virtualization \
> >   .../meta-webserver \
> >   .../meta-multimedia \
> >   .../meta-filesystems \
> >   .../meta-networking \
> >   .../meta-python \
> >   .../meta-oe \
> >   .../meta-poky \
> >   .../meta \
> > "
> >
> > We have them configured like this to as best as possible match the
> > layer priorities. It is not perfect (e.g., meta-poky prepends to
> > BBPATH instead of appending like all the other layers do), but it
> > has resulted in the least surprises regarding things that are based
> > on BBPATH and things that are based on layer priorities.
> 
> We need to rewrite how this all works and remove some of the options as
> it is all too complex and everyone is putting it together differently
> and hoping for the best :(.
> 
> Trying to "support" the number of possible combinations that people
> might put things together is problematic. The ask is that everything
> works regardless of how you configure it and nobody even
> understands/agrees on the basic rules.

I think one of the biggest problems here actually is the freedom 
provided by the current solution for how layers are added and 
configured, and I believe we actually want to make it much more 
rigid. Which of course will make people scream (possibly 
including myself).

> If you don't understand my concern, think about how you'd recreate that
> setup just starting from core and using bitbake-layers add-layer. I
> don't think you can.

Well, actually, I do have some experience in the area. While we 
do not use bitbake-layers add-layer, but rather use the layers 
as specified in our repo manifests, this still means we have a 
different set of layers for each manifest that needs to be put 
into the correct order in BBLAYERS. In a perfect world, this 
would be done by taking layer priorities and layer dependencies 
into consideration. However, we have cheated in our current 
solution, so instead we have a static list for the order of 
known layers, and any unknown layers go on top (in our case 
these are typically project layers that depend on the known 
layers anyway).
> 
> It is too late to do anything about it right now and I've put off
> trying to improve things as I know the shear amount of complaints I'll
> get but there is a problem here.

I expect you to have given this a lot more thought over the 
years than I have, so please take my naïve ideas below for 
what they are.

> 
> Cheers,
> 
> Richard

I would love to see an addlayer command (or something similar) 
that would hide all the gory details of layer priorities, 
dependencies, and making sure it is consistent when applying 
bbappends and the order .conf files are read, etc, and avoids 
problems with different layers having their own ideas about how 
to do things. Unfortunately, I do realize this is an enormous 
job, and getting all the details right will probably be near 
impossible, especially as everyone undoubtedly have their own 
ideas about how layer configuration should be done (I know I do). 
And, unfortunately, I also have a pretty good idea of who would 
have to do most work to make anything like this happen.
(I have a feeling I'm not selling this idea very well... ☹)

Another thing I would like to see is that the order in BBLAYERS 
does not matter. Instead, the layer dependencies should determine 
the order, pretty much like how the task dependencies decide the 
order the tasks are executed. Unfortunately, I do not know if 
even this is possible, or if my view of how the layers are 
configured is too simple.

And if I may be a bit adventurous, I could even see the BBLAYERS 
variable being removed altogether (or at least not used as input), 
and instead be replaced by, e.g., a drop directory where you 
create links to the layers you want to use in a specific 
configuration. Then adding/removing a layer to the build is just a 
matter of adding/removing a link, which is easily done by tools 
like bitbake-setup, bitbake-layers, kas, repo, or even just ln -s, 
without having to manipulate an actual configuration file, which 
is always error prone.

//Peter

Re: [OE-core] [PATCH] sstate/sstatesig: Abstract dummy package architectures into layer.conf settings

[Richard Purdie]

On Tue, 2026-03-17 at 17:41 +0000, Peter Kjellerstedt wrote:
> 
> I think one of the biggest problems here actually is the freedom 
> provided by the current solution for how layers are added and 
> configured, and I believe we actually want to make it much more 
> rigid. Which of course will make people scream (possibly 
> including myself).

Agreed, there are just too many options currently. Anything we choose
to remove or restrict will upset someone though.

> 
> I would love to see an addlayer command (or something similar) 
> that would hide all the gory details of layer priorities, 

Oddly enough, somewhere I have a patch which does add an addlayer
directive so it was something I already experimented with.

The sticking point was that I really wanted to just drop the layer
priority part of the code and I couldn't face the number of complaints
that might generate.

> dependencies, and making sure it is consistent when applying 
> bbappends and the order .conf files are read, etc, and avoids 
> problems with different layers having their own ideas about how 
> to do things. Unfortunately, I do realize this is an enormous 
> job, and getting all the details right will probably be near 
> impossible, especially as everyone undoubtedly have their own 
> ideas about how layer configuration should be done (I know I do). 
> And, unfortunately, I also have a pretty good idea of who would 
> have to do most work to make anything like this happen.
> (I have a feeling I'm not selling this idea very well... ☹)

The last time I touched this issue, I got into a lot of trouble very
quickly. It needs time available to handle all that correctly and it
simply isn't something I've had.

> Another thing I would like to see is that the order in BBLAYERS 
> does not matter. Instead, the layer dependencies should determine 
> the order, pretty much like how the task dependencies decide the 
> order the tasks are executed. Unfortunately, I do not know if 
> even this is possible, or if my view of how the layers are 
> configured is too simple.

I'm certainly want to explore that idea. We need to work out what
issues people may run into that couldn't be solved in that case and
whether we're prepared to accept those compromises.

> And if I may be a bit adventurous, I could even see the BBLAYERS 
> variable being removed altogether (or at least not used as input), 
> and instead be replaced by, e.g., a drop directory where you 
> create links to the layers you want to use in a specific 
> configuration. Then adding/removing a layer to the build is just a 
> matter of adding/removing a link, which is easily done by tools 
> like bitbake-setup, bitbake-layers, kas, repo, or even just ln -s, 
> without having to manipulate an actual configuration file, which 
> is always error prone.

I think BBLAYERS as a list of places to look isn't the main issue at
this point but I appreciate the idea.

Cheers,

Richard