public inbox for cip-dev@lists.cip-project.org
 help / color / mirror / Atom feed
From: "MOESSBAUER, Felix" <felix.moessbauer@siemens.com>
To: "Kiszka, Jan" <jan.kiszka@siemens.com>,
	Uladzimir Bely <ubely@ilbers.de>,
	"cip-dev@lists.cip-project.org" <cip-dev@lists.cip-project.org>,
	"Gylstorff, Quirin" <quirin.gylstorff@siemens.com>
Subject: Re: [isar-cip-core][PATCH] IMAGE_TYPEDEP:swu: Don't depend on wic
Date: Mon, 5 Jun 2023 07:13:56 +0000	[thread overview]
Message-ID: <0fc8aa184fe24a549be85f87a69a0edb@siemens.com> (raw)
In-Reply-To: <cb62ac04-f64e-192e-7d00-e411f4422cea@siemens.com>

>On 16.05.23 10:50, Uladzimir Bely wrote:
>> Settings IMAGE_FSTYPE to something like "ext4 swu" or "wic.xz swu"
>> causes uncompressed '.wic' image left non-removed after the build 
>> finished. This is caused by indirect dependency on "wic" in swupdate 
>> bbclass that can't be overriden by the user in local.conf.
>> 
>> This patch removes this depencency. If the user want to use some wic 
>> partitions to be packed into .swu bundle, they could simply add 
>> directly add "wic" or "wic.xz" to IMAGE_FSTYPE.
>> 
>> Signed-off-by: Uladzimir Bely <ubely@ilbers.de>
>> ---
>>  classes/swupdate.bbclass | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/classes/swupdate.bbclass b/classes/swupdate.bbclass index 
>> 9a4d509..6f034c1 100644
>> --- a/classes/swupdate.bbclass
>> +++ b/classes/swupdate.bbclass
>> @@ -31,7 +31,7 @@ SWU_SIGNATURE_TYPE ?= "rsa"
>>  
>>  SWU_BUILDCHROOT_IMAGE_FILE ?= "${PP_DEPLOY}/${@os.path.basename(d.getVar('SWU_IMAGE_FILE'))}"
>>  
>> -IMAGE_TYPEDEP:swu = "wic ${SWU_ROOTFS_TYPE}${@get_swu_compression_type(d)}"
>> +IMAGE_TYPEDEP:swu = "${SWU_ROOTFS_TYPE}${@get_swu_compression_type(d)}"
>>  IMAGER_INSTALL:swu += "cpio ${@'openssl' if bb.utils.to_boolean(d.getVar('SWU_SIGNED')) else ''}"
>>  
>>  IMAGE_SRC_URI:swu = "file://${SWU_DESCRIPTION_FILE}.tmpl"
>
>Oops, this almost fell through the cracks.
>
> I'm indeed not seeing anything in this class referencing wic, so this removal seems logical to me. I'm just concerned if we have downstream users relying on >it and then seeing a hard to understand error. Any thoughts?

Downstream layers need to adapt to the new interface anyways (if they don't use the plain version provided by CIP).
The .wic is not needed and should be removed.

Acked!

Felix

> Jan

  reply	other threads:[~2023-06-05 11:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-16  8:50 [isar-cip-core][PATCH] IMAGE_TYPEDEP:swu: Don't depend on wic Uladzimir Bely
2023-06-04 20:37 ` Jan Kiszka
2023-06-05  7:13   ` MOESSBAUER, Felix [this message]
2023-06-06  7:09     ` Jan Kiszka
2023-06-06  7:57       ` Jan Kiszka
2023-06-07  6:49         ` Uladzimir Bely
2023-06-07  9:03         ` Uladzimir Bely
2023-06-07 12:21           ` Uladzimir Bely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0fc8aa184fe24a549be85f87a69a0edb@siemens.com \
    --to=felix.moessbauer@siemens.com \
    --cc=cip-dev@lists.cip-project.org \
    --cc=jan.kiszka@siemens.com \
    --cc=quirin.gylstorff@siemens.com \
    --cc=ubely@ilbers.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox