When using the cip-core layer in another layer that has a slightly
different directory structure, bitbake is not able to resolve the
included files.

To fix this, we simply add the full path to the file so bitbake is able
to locate it independent of the downstream layer configuration.

Signed-off-by: Felix Moessbauer <felix.moessbauer@...>
---
kas/opt/ebg-swu.yml | 2 +-
kas/opt/swupdate.yml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kas/opt/ebg-swu.yml b/kas/opt/ebg-swu.yml
index 8b3ffec..78227f1 100644
--- a/kas/opt/ebg-swu.yml
+++ b/kas/opt/ebg-swu.yml
@@ -20,7 +20,7 @@ local_conf_header:
SWUPDATE_BOOTLOADER = "efibootguard"
IMAGE_INSTALL_remove = "u-boot-script"
ebg_swu_image_options: |
- CIP_IMAGE_OPTIONS_append = " efibootguard.inc image-uuid.inc"
+ CIP_IMAGE_OPTIONS_append = " recipes-core/images/efibootguard.inc recipes-core/images/image-uuid.inc"
initramfs: |
INITRAMFS_INSTALL_append = " initramfs-abrootfs-hook"
firmware-binaries: |
diff --git a/kas/opt/swupdate.yml b/kas/opt/swupdate.yml
index 8ba03c9..e32ce20 100644
--- a/kas/opt/swupdate.yml
+++ b/kas/opt/swupdate.yml
@@ -16,7 +16,7 @@ header:

local_conf_header:
image-option-swupdate: |
- CIP_IMAGE_OPTIONS_append = " swupdate.inc"
+ CIP_IMAGE_OPTIONS_append = " recipes-core/images/swupdate.inc"

wic-swu: |
IMAGE_CLASSES += "squashfs"
--
2.30.2

On 10/1/22 06:52, Felix Moessbauer wrote:

When using the cip-core layer in another layer that has a slightly
different directory structure, bitbake is not able to resolve the
included files.
To fix this, we simply add the full path to the file so bitbake is able
to locate it independent of the downstream layer configuration.
Signed-off-by: Felix Moessbauer <felix.moessbauer@...>
---
kas/opt/ebg-swu.yml | 2 +-
kas/opt/swupdate.yml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kas/opt/ebg-swu.yml b/kas/opt/ebg-swu.yml
index 8b3ffec..78227f1 100644
--- a/kas/opt/ebg-swu.yml
+++ b/kas/opt/ebg-swu.yml
@@ -20,7 +20,7 @@ local_conf_header:
SWUPDATE_BOOTLOADER = "efibootguard"
IMAGE_INSTALL_remove = "u-boot-script"
ebg_swu_image_options: |
- CIP_IMAGE_OPTIONS_append = " efibootguard.inc image-uuid.inc"
+ CIP_IMAGE_OPTIONS_append = " recipes-core/images/efibootguard.inc recipes-core/images/image-uuid.inc"
initramfs: |
INITRAMFS_INSTALL_append = " initramfs-abrootfs-hook"
firmware-binaries: |
diff --git a/kas/opt/swupdate.yml b/kas/opt/swupdate.yml
index 8ba03c9..e32ce20 100644
--- a/kas/opt/swupdate.yml
+++ b/kas/opt/swupdate.yml
@@ -16,7 +16,7 @@ header:
local_conf_header:
image-option-swupdate: |
- CIP_IMAGE_OPTIONS_append = " swupdate.inc"
+ CIP_IMAGE_OPTIONS_append = " recipes-core/images/swupdate.inc"
wic-swu: |
IMAGE_CLASSES += "squashfs"

It would be nice if we could write the options without the full path necessary.

Quirin

On 07.10.22 10:53, Moessbauer, Felix (T CED SES-DE) wrote:

-----Original Message-----
From: Gylstorff, Quirin (T CED SES-DE) <quirin.gylstorff@...>
Sent: Friday, October 7, 2022 4:08 PM
To: Moessbauer, Felix (T CED SES-DE) <felix.moessbauer@...>; cip-
dev@...; Kiszka, Jan (T CED) <jan.kiszka@...>
Subject: Re: [isar-cip-core][PATCH 1/1] use qualified path for
CIP_IMAGE_OPTIONS



On 10/1/22 06:52, Felix Moessbauer wrote:

When using the cip-core layer in another layer that has a slightly
different directory structure, bitbake is not able to resolve the
included files.

To fix this, we simply add the full path to the file so bitbake is
able to locate it independent of the downstream layer configuration.

Signed-off-by: Felix Moessbauer <felix.moessbauer@...>
---
kas/opt/ebg-swu.yml | 2 +-
kas/opt/swupdate.yml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kas/opt/ebg-swu.yml b/kas/opt/ebg-swu.yml index
8b3ffec..78227f1 100644
--- a/kas/opt/ebg-swu.yml
+++ b/kas/opt/ebg-swu.yml
@@ -20,7 +20,7 @@ local_conf_header:
SWUPDATE_BOOTLOADER = "efibootguard"
IMAGE_INSTALL_remove = "u-boot-script"
ebg_swu_image_options: |
- CIP_IMAGE_OPTIONS_append = " efibootguard.inc image-uuid.inc"
+ CIP_IMAGE_OPTIONS_append = " recipes-core/images/efibootguard.inc

recipes-core/images/image-uuid.inc"

initramfs: |
INITRAMFS_INSTALL_append = " initramfs-abrootfs-hook"
firmware-binaries: |
diff --git a/kas/opt/swupdate.yml b/kas/opt/swupdate.yml index
8ba03c9..e32ce20 100644
--- a/kas/opt/swupdate.yml
+++ b/kas/opt/swupdate.yml
@@ -16,7 +16,7 @@ header:

local_conf_header:
image-option-swupdate: |
- CIP_IMAGE_OPTIONS_append = " swupdate.inc"
+ CIP_IMAGE_OPTIONS_append = " recipes-core/images/swupdate.inc"

wic-swu: |
IMAGE_CLASSES += "squashfs"

It would be nice if we could write the options without the full path necessary.

Hi Quirin,

This unfortunately does not work, as the options are passed to an "include" or "require" bitbake keyword.
And by that, we have to comply with the logic of the keyword.
Or do I miss something, @Jan?

I suppose the key question is whether you are consuming
CIP_IMAGE_OPTIONS in your own image recipe or via
cip-core/recipes-core/images/cip-core-image.bb. The latter should work -
or are we simply missing a

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

in cip-core-image.bb?

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

On 07.10.22 11:40, Moessbauer, Felix (T CED SES-DE) wrote:

-----Original Message-----
From: Kiszka, Jan (T CED) <jan.kiszka@...>
Sent: Friday, October 7, 2022 5:11 PM
To: Moessbauer, Felix (T CED SES-DE) <felix.moessbauer@...>;
Gylstorff, Quirin (T CED SES-DE) <quirin.gylstorff@...>
Cc: cip-dev@...
Subject: Re: [isar-cip-core][PATCH 1/1] use qualified path for
CIP_IMAGE_OPTIONS

On 07.10.22 10:53, Moessbauer, Felix (T CED SES-DE) wrote:

-----Original Message-----
From: Gylstorff, Quirin (T CED SES-DE) <quirin.gylstorff@...>
Sent: Friday, October 7, 2022 4:08 PM
To: Moessbauer, Felix (T CED SES-DE) <felix.moessbauer@...>;
cip- dev@...; Kiszka, Jan (T CED)
<jan.kiszka@...>
Subject: Re: [isar-cip-core][PATCH 1/1] use qualified path for
CIP_IMAGE_OPTIONS



On 10/1/22 06:52, Felix Moessbauer wrote:

When using the cip-core layer in another layer that has a slightly
different directory structure, bitbake is not able to resolve the
included files.

To fix this, we simply add the full path to the file so bitbake is
able to locate it independent of the downstream layer configuration.

Signed-off-by: Felix Moessbauer <felix.moessbauer@...>
---
kas/opt/ebg-swu.yml | 2 +-
kas/opt/swupdate.yml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kas/opt/ebg-swu.yml b/kas/opt/ebg-swu.yml index
8b3ffec..78227f1 100644
--- a/kas/opt/ebg-swu.yml
+++ b/kas/opt/ebg-swu.yml
@@ -20,7 +20,7 @@ local_conf_header:
SWUPDATE_BOOTLOADER = "efibootguard"
IMAGE_INSTALL_remove = "u-boot-script"
ebg_swu_image_options: |
- CIP_IMAGE_OPTIONS_append = " efibootguard.inc image-uuid.inc"
+ CIP_IMAGE_OPTIONS_append = "
+ recipes-core/images/efibootguard.inc

recipes-core/images/image-uuid.inc"

initramfs: |
INITRAMFS_INSTALL_append = " initramfs-abrootfs-hook"
firmware-binaries: |
diff --git a/kas/opt/swupdate.yml b/kas/opt/swupdate.yml index
8ba03c9..e32ce20 100644
--- a/kas/opt/swupdate.yml
+++ b/kas/opt/swupdate.yml
@@ -16,7 +16,7 @@ header:

local_conf_header:
image-option-swupdate: |
- CIP_IMAGE_OPTIONS_append = " swupdate.inc"
+ CIP_IMAGE_OPTIONS_append = " recipes-core/images/swupdate.inc"

wic-swu: |
IMAGE_CLASSES += "squashfs"

It would be nice if we could write the options without the full path necessary.

Hi Quirin,

This unfortunately does not work, as the options are passed to an "include" or

"require" bitbake keyword.

And by that, we have to comply with the logic of the keyword.
Or do I miss something, @Jan?

I suppose the key question is whether you are consuming CIP_IMAGE_OPTIONS
in your own image recipe or via cip-core/recipes-core/images/cip-core-
image.bb. The latter should work - or are we simply missing a

I just consume the CIP_IMAGE_OPTIONS in my image, as the cip-core-image also contains "customization", which I do not need in my image.
Maybe these should be carved out as well.

Everyone needs customizations in their images - just overload it.

And whatever ends up in CIP_IMAGE_OPTIONS should be "standalone", meaning it should always contain full paths to avoid name conflicts with recipes in the downstream layer.

CIP_IMAGE_OPTIONS were so far designed for cip images, that's why it has
"CIP_IMAGE" in its name.

And there should be a bold statement in the docs that downstream layers shall use "requires" for including CIP_IMAGE_OPTIONS as missed includes lead to weird errors in later steps when assembling the image.

That is that nasty bitbake syntax again - we should fix cip-core-image
to use "require", rather than misleading "include", to avoid spreading
that mistake. (And swupdate_2021.11-1+debian-gbp.bb should be fixed as
well...)

But the key question remains if we should convert "CIP_IMAGE_OPTIONS" to
a generic "IMAGE_OPTIONS". I'm not yet sure at which level to do the cut
and suggest the reuse. Before tuning details, it's likely the right time
to rethink the overall concept (which I postponed so far).

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

On 07.10.22 13:25, Moessbauer, Felix (T CED SES-DE) wrote:

-----Original Message-----
From: Kiszka, Jan (T CED) <jan.kiszka@...>
Sent: Friday, October 7, 2022 6:29 PM
To: Moessbauer, Felix (T CED SES-DE) <felix.moessbauer@...>;
Gylstorff, Quirin (T CED SES-DE) <quirin.gylstorff@...>
Cc: cip-dev@...
Subject: Re: [isar-cip-core][PATCH 1/1] use qualified path for
CIP_IMAGE_OPTIONS

On 07.10.22 11:40, Moessbauer, Felix (T CED SES-DE) wrote:

-----Original Message-----
From: Kiszka, Jan (T CED) <jan.kiszka@...>
Sent: Friday, October 7, 2022 5:11 PM
To: Moessbauer, Felix (T CED SES-DE) <felix.moessbauer@...>;
Gylstorff, Quirin (T CED SES-DE) <quirin.gylstorff@...>
Cc: cip-dev@...
Subject: Re: [isar-cip-core][PATCH 1/1] use qualified path for
CIP_IMAGE_OPTIONS

On 07.10.22 10:53, Moessbauer, Felix (T CED SES-DE) wrote:

-----Original Message-----
From: Gylstorff, Quirin (T CED SES-DE)
<quirin.gylstorff@...>
Sent: Friday, October 7, 2022 4:08 PM
To: Moessbauer, Felix (T CED SES-DE)
<felix.moessbauer@...>;
cip- dev@...; Kiszka, Jan (T CED)
<jan.kiszka@...>
Subject: Re: [isar-cip-core][PATCH 1/1] use qualified path for
CIP_IMAGE_OPTIONS



On 10/1/22 06:52, Felix Moessbauer wrote:

When using the cip-core layer in another layer that has a slightly
different directory structure, bitbake is not able to resolve the
included files.

To fix this, we simply add the full path to the file so bitbake is
able to locate it independent of the downstream layer configuration.

Signed-off-by: Felix Moessbauer <felix.moessbauer@...>
---
kas/opt/ebg-swu.yml | 2 +-
kas/opt/swupdate.yml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kas/opt/ebg-swu.yml b/kas/opt/ebg-swu.yml index
8b3ffec..78227f1 100644
--- a/kas/opt/ebg-swu.yml
+++ b/kas/opt/ebg-swu.yml
@@ -20,7 +20,7 @@ local_conf_header:
SWUPDATE_BOOTLOADER = "efibootguard"
IMAGE_INSTALL_remove = "u-boot-script"
ebg_swu_image_options: |
- CIP_IMAGE_OPTIONS_append = " efibootguard.inc image-uuid.inc"
+ CIP_IMAGE_OPTIONS_append = "
+ recipes-core/images/efibootguard.inc

recipes-core/images/image-uuid.inc"

initramfs: |
INITRAMFS_INSTALL_append = " initramfs-abrootfs-hook"
firmware-binaries: |
diff --git a/kas/opt/swupdate.yml b/kas/opt/swupdate.yml index
8ba03c9..e32ce20 100644
--- a/kas/opt/swupdate.yml
+++ b/kas/opt/swupdate.yml
@@ -16,7 +16,7 @@ header:

local_conf_header:
image-option-swupdate: |
- CIP_IMAGE_OPTIONS_append = " swupdate.inc"
+ CIP_IMAGE_OPTIONS_append = " recipes-core/images/swupdate.inc"

wic-swu: |
IMAGE_CLASSES += "squashfs"

It would be nice if we could write the options without the full path

necessary.

Hi Quirin,

This unfortunately does not work, as the options are passed to an
"include" or

"require" bitbake keyword.

And by that, we have to comply with the logic of the keyword.
Or do I miss something, @Jan?

I suppose the key question is whether you are consuming
CIP_IMAGE_OPTIONS in your own image recipe or via
cip-core/recipes-core/images/cip-core-
image.bb. The latter should work - or are we simply missing a

I just consume the CIP_IMAGE_OPTIONS in my image, as the cip-core-image

also contains "customization", which I do not need in my image.

Maybe these should be carved out as well.

Everyone needs customizations in their images - just overload it.

I dislike the <VAR>_remove pattern that has already spread across layers as upstream layers (including ISAR itself) tend to mix up infrastructure and examples.

Nope, I meant implement your own customization recipe - which is what
you will do anyway.

And please don't dictate how a downstream user does it's customization.

I have seen no layer so far that does not have a customization package.

From a base image, I would never expect to bring any customizations or examples.
If that is the case, I simply don't use it as a base but copy the pattern (which breaks the build here).

Anyway, we can define a cip-core-image-base and make the cip-core-image
the usable one for cip-core itself (demo, testing etc.). That would also
allow to push some parameters out of kas-cip.yml, which is ugly anyway.

And whatever ends up in CIP_IMAGE_OPTIONS should be "standalone",

meaning it should always contain full paths to avoid name conflicts with recipes
in the downstream layer.

CIP_IMAGE_OPTIONS were so far designed for cip images, that's why it has
"CIP_IMAGE" in its name.

Fine, but is CIP a pattern database that users should copy from or a layer to be included?
I vote for the layer and inheritance approach instead of the database.

And there should be a bold statement in the docs that downstream layers shall

use "requires" for including CIP_IMAGE_OPTIONS as missed includes lead to
weird errors in later steps when assembling the image.

That is that nasty bitbake syntax again - we should fix cip-core-image to use
"require", rather than misleading "include", to avoid spreading that mistake.
(And swupdate_2021.11-1+debian-gbp.bb should be fixed as
well...)

I don't know if "requires <nothing>" works, but if that works then please switch.

Yes, works equally well.

But the key question remains if we should convert "CIP_IMAGE_OPTIONS" to a
generic "IMAGE_OPTIONS". I'm not yet sure at which level to do the cut and
suggest the reuse. Before tuning details, it's likely the right time to rethink the
overall concept (which I postponed so far).

IMHO, CIP_IMAGE_OPTIONS is fine as IMAGE_OPTIONS is too generic.
Downstream layers (basically leaves of the inheritance tree) might already use that variable and this might conflict.

Why not simply fix this include before rethinking the overall concept?
The CIP core layer is pretty easy to integrate into downstream layers, except for this nasty detail.

Nope, it's not yet. We have too many ways to consume cip-core downstream
already, and that makes me unhappy. I was hoping that things naturally
fit, but the way you picked things up showed that they don't.

Are you also using the kas option files as-they-are then?

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

On 07.10.22 15:07, Moessbauer, Felix (T CED SES-DE) wrote:

On 10/1/22 06:52, Felix Moessbauer wrote:

When using the cip-core layer in another layer that has a
slightly different directory structure, bitbake is not able to
resolve the included files.

To fix this, we simply add the full path to the file so bitbake
is able to locate it independent of the downstream layer configuration.

Signed-off-by: Felix Moessbauer <felix.moessbauer@...>
---
kas/opt/ebg-swu.yml | 2 +-
kas/opt/swupdate.yml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kas/opt/ebg-swu.yml b/kas/opt/ebg-swu.yml index
8b3ffec..78227f1 100644
--- a/kas/opt/ebg-swu.yml
+++ b/kas/opt/ebg-swu.yml
@@ -20,7 +20,7 @@ local_conf_header:
SWUPDATE_BOOTLOADER = "efibootguard"
IMAGE_INSTALL_remove = "u-boot-script"
ebg_swu_image_options: |
- CIP_IMAGE_OPTIONS_append = " efibootguard.inc image-uuid.inc"
+ CIP_IMAGE_OPTIONS_append = "
+ recipes-core/images/efibootguard.inc

recipes-core/images/image-uuid.inc"

initramfs: |
INITRAMFS_INSTALL_append = " initramfs-abrootfs-hook"
firmware-binaries: |
diff --git a/kas/opt/swupdate.yml b/kas/opt/swupdate.yml index
8ba03c9..e32ce20 100644
--- a/kas/opt/swupdate.yml
+++ b/kas/opt/swupdate.yml
@@ -16,7 +16,7 @@ header:

local_conf_header:
image-option-swupdate: |
- CIP_IMAGE_OPTIONS_append = " swupdate.inc"
+ CIP_IMAGE_OPTIONS_append = " recipes-

core/images/swupdate.inc"

wic-swu: |
IMAGE_CLASSES += "squashfs"

It would be nice if we could write the options without the full
path

necessary.

Hi Quirin,

This unfortunately does not work, as the options are passed to an
"include" or

"require" bitbake keyword.

And by that, we have to comply with the logic of the keyword.
Or do I miss something, @Jan?

I suppose the key question is whether you are consuming
CIP_IMAGE_OPTIONS in your own image recipe or via
cip-core/recipes-core/images/cip-core-
image.bb. The latter should work - or are we simply missing a

I just consume the CIP_IMAGE_OPTIONS in my image, as the
cip-core-image

also contains "customization", which I do not need in my image.

Maybe these should be carved out as well.

Everyone needs customizations in their images - just overload it.

I dislike the <VAR>_remove pattern that has already spread across layers as

upstream layers (including ISAR itself) tend to mix up infrastructure and
examples.

Nope, I meant implement your own customization recipe - which is what you
will do anyway.

And please don't dictate how a downstream user does it's customization.

I have seen no layer so far that does not have a customization package.

From a base image, I would never expect to bring any customizations or

examples.

If that is the case, I simply don't use it as a base but copy the pattern (which

breaks the build here).

Anyway, we can define a cip-core-image-base and make the cip-core-image the
usable one for cip-core itself (demo, testing etc.). That would also allow to push
some parameters out of kas-cip.yml, which is ugly anyway.

Yes, I agree. Setting bb includes via kas felt somehow strange to me.

And whatever ends up in CIP_IMAGE_OPTIONS should be "standalone",

meaning it should always contain full paths to avoid name conflicts
with recipes in the downstream layer.

CIP_IMAGE_OPTIONS were so far designed for cip images, that's why it
has "CIP_IMAGE" in its name.

Fine, but is CIP a pattern database that users should copy from or a layer to be

included?

I vote for the layer and inheritance approach instead of the database.

And there should be a bold statement in the docs that downstream
layers shall

use "requires" for including CIP_IMAGE_OPTIONS as missed includes
lead to weird errors in later steps when assembling the image.

That is that nasty bitbake syntax again - we should fix
cip-core-image to use "require", rather than misleading "include", to avoid

spreading that mistake.

(And swupdate_2021.11-1+debian-gbp.bb should be fixed as
well...)

I don't know if "requires <nothing>" works, but if that works then please

switch.

Yes, works equally well.

But the key question remains if we should convert "CIP_IMAGE_OPTIONS"
to a generic "IMAGE_OPTIONS". I'm not yet sure at which level to do
the cut and suggest the reuse. Before tuning details, it's likely the
right time to rethink the overall concept (which I postponed so far).

IMHO, CIP_IMAGE_OPTIONS is fine as IMAGE_OPTIONS is too generic.
Downstream layers (basically leaves of the inheritance tree) might already use

that variable and this might conflict.

Why not simply fix this include before rethinking the overall concept?
The CIP core layer is pretty easy to integrate into downstream layers, except

for this nasty detail.

Nope, it's not yet. We have too many ways to consume cip-core downstream
already, and that makes me unhappy. I was hoping that things naturally fit, but
the way you picked things up showed that they don't.

Are you also using the kas option files as-they-are then?

Yes, via includes.
But this part is actually not trivial, as you have to include the files in the correct order and play around with the weak assignments, order of layer.conf, local.conf and machine.conf.
And unfortunately you cannot patch kas files with kas, so I was not able to patch the paths to the includes.
Instead I had to work around by using the following pattern (which is extremely ugly):
CIP_IMAGE_OPTIONS_remove = "efibootguard.inc image-uuid.inc swupdate.inc"
CIP_IMAGE_OPTIONS_append = " recipes-core/images/efibootguard.inc recipes-core/images

Maybe all that is an antipattern and I should have simply used bitbake to include the recipes directly instead of re-using the kas files from cip.
IMO there is too much logic in the kas files which should be shifted to the recipes and toggled via BB variables.
But that's something which should be stated in the docs.

Yes, that's also why I was not using the kas files themselves in
meta-iot2050. But that one is also not on the latest isar-cip-core
version yet, so not fully comparable here.

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux

On 10/1/22 06:52, Felix Moessbauer wrote:

When using the cip-core layer in another layer that has a
slightly different directory structure, bitbake is not able to
resolve the included files.

To fix this, we simply add the full path to the file so bitbake
is able to locate it independent of the downstream layer configuration.

Signed-off-by: Felix Moessbauer <felix.moessbauer@...>
---
kas/opt/ebg-swu.yml | 2 +-
kas/opt/swupdate.yml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kas/opt/ebg-swu.yml b/kas/opt/ebg-swu.yml index
8b3ffec..78227f1 100644
--- a/kas/opt/ebg-swu.yml
+++ b/kas/opt/ebg-swu.yml
@@ -20,7 +20,7 @@ local_conf_header:
SWUPDATE_BOOTLOADER = "efibootguard"
IMAGE_INSTALL_remove = "u-boot-script"
ebg_swu_image_options: |
- CIP_IMAGE_OPTIONS_append = " efibootguard.inc image-uuid.inc"
+ CIP_IMAGE_OPTIONS_append = "
+ recipes-core/images/efibootguard.inc

recipes-core/images/image-uuid.inc"

initramfs: |
INITRAMFS_INSTALL_append = " initramfs-abrootfs-hook"
firmware-binaries: |
diff --git a/kas/opt/swupdate.yml b/kas/opt/swupdate.yml index
8ba03c9..e32ce20 100644
--- a/kas/opt/swupdate.yml
+++ b/kas/opt/swupdate.yml
@@ -16,7 +16,7 @@ header:

local_conf_header:
image-option-swupdate: |
- CIP_IMAGE_OPTIONS_append = " swupdate.inc"
+ CIP_IMAGE_OPTIONS_append = " recipes-

core/images/swupdate.inc"

wic-swu: |
IMAGE_CLASSES += "squashfs"

It would be nice if we could write the options without the full
path

necessary.

Hi Quirin,

This unfortunately does not work, as the options are passed to an
"include" or

"require" bitbake keyword.

And by that, we have to comply with the logic of the keyword.
Or do I miss something, @Jan?

I suppose the key question is whether you are consuming
CIP_IMAGE_OPTIONS in your own image recipe or via
cip-core/recipes-core/images/cip-core-
image.bb. The latter should work - or are we simply missing a

I just consume the CIP_IMAGE_OPTIONS in my image, as the
cip-core-image

also contains "customization", which I do not need in my image.

Maybe these should be carved out as well.

Everyone needs customizations in their images - just overload it.

I dislike the <VAR>_remove pattern that has already spread across layers as

upstream layers (including ISAR itself) tend to mix up infrastructure and
examples.

Nope, I meant implement your own customization recipe - which is what you
will do anyway.

And please don't dictate how a downstream user does it's customization.

I have seen no layer so far that does not have a customization package.

From a base image, I would never expect to bring any customizations or

examples.

If that is the case, I simply don't use it as a base but copy the pattern (which

breaks the build here).

Anyway, we can define a cip-core-image-base and make the cip-core-image the
usable one for cip-core itself (demo, testing etc.). That would also allow to push
some parameters out of kas-cip.yml, which is ugly anyway.

Yes, I agree. Setting bb includes via kas felt somehow strange to me.

And whatever ends up in CIP_IMAGE_OPTIONS should be "standalone",

meaning it should always contain full paths to avoid name conflicts
with recipes in the downstream layer.

CIP_IMAGE_OPTIONS were so far designed for cip images, that's why it
has "CIP_IMAGE" in its name.

Fine, but is CIP a pattern database that users should copy from or a layer to be

included?

I vote for the layer and inheritance approach instead of the database.

And there should be a bold statement in the docs that downstream
layers shall

use "requires" for including CIP_IMAGE_OPTIONS as missed includes
lead to weird errors in later steps when assembling the image.

That is that nasty bitbake syntax again - we should fix
cip-core-image to use "require", rather than misleading "include", to avoid

spreading that mistake.

(And swupdate_2021.11-1+debian-gbp.bb should be fixed as
well...)

I don't know if "requires <nothing>" works, but if that works then please

switch.

Yes, works equally well.

But the key question remains if we should convert "CIP_IMAGE_OPTIONS"
to a generic "IMAGE_OPTIONS". I'm not yet sure at which level to do
the cut and suggest the reuse. Before tuning details, it's likely the
right time to rethink the overall concept (which I postponed so far).

IMHO, CIP_IMAGE_OPTIONS is fine as IMAGE_OPTIONS is too generic.
Downstream layers (basically leaves of the inheritance tree) might already use

that variable and this might conflict.

Why not simply fix this include before rethinking the overall concept?
The CIP core layer is pretty easy to integrate into downstream layers, except

for this nasty detail.

Nope, it's not yet. We have too many ways to consume cip-core downstream
already, and that makes me unhappy. I was hoping that things naturally fit, but
the way you picked things up showed that they don't.

Are you also using the kas option files as-they-are then?

Yes, via includes.
But this part is actually not trivial, as you have to include the files in the correct order and play around with the weak assignments, order of layer.conf, local.conf and machine.conf.
And unfortunately you cannot patch kas files with kas, so I was not able to patch the paths to the includes.
Instead I had to work around by using the following pattern (which is extremely ugly):
CIP_IMAGE_OPTIONS_remove = "efibootguard.inc image-uuid.inc swupdate.inc"
CIP_IMAGE_OPTIONS_append = " recipes-core/images/efibootguard.inc recipes-core/images

Maybe all that is an antipattern and I should have simply used bitbake to include the recipes directly instead of re-using the kas files from cip.
IMO there is too much logic in the kas files which should be shifted to the recipes and toggled via BB variables.
But that's something which should be stated in the docs.

Felix

Jan

--
Siemens AG, Technology
Competence Center Embedded Linux