From: Claudius Heine <claudius.heine.ext@siemens.com>
To: "[ext] Quirin Gylstorff" <quirin.gylstorff@siemens.com>,
Henning Schild <henning.schild@siemens.com>
Cc: isar-users@googlegroups.com
Subject: Re: [PATCH] meta/classes:Add wic tooling for related images
Date: Tue, 23 Jul 2019 16:56:47 +0200 [thread overview]
Message-ID: <a899e7d4-b697-804e-22bb-5875d3ae8f64@siemens.com> (raw)
In-Reply-To: <c2ad73fe-60a2-17ff-8d42-3eb3c3040ffb@siemens.com>
On 23/07/2019 16.42, [ext] Quirin Gylstorff wrote:
>
>
> On 7/23/19 4:18 PM, Henning Schild wrote:
>> I do not remember why it is done like that. The original code most
>> likely came from me. But probably at a time where IMAGER_INSTALL did
>> not yet exist. So it effectively messed with IMAGE_PREINSTALL.
>>
>> Would have to go back in history and read changes. If my assumption
>> (legacy left overs from before IMAGER_INSTALL) is correct this patch is
>> probably correct. But maybe there is another reason.
>>
>> Did you go back a few "git blame"s and read the commit messages and
>> comments around the python function?
>>
>> Henning
>
>
> The code was originally created with commit 8c4d3ed8 to replace a
> workaround for the image creation. The commit switches to the
> IMAGER_INSTALL mechanism away from some hack.
Well this code was originally written in commit:
5026e58f08aba98a01f7bef160d0a3163219b6c4
Author: Henning Schild <henning.schild@siemens.com>
Date: Fri Apr 13 16:19:00 2018 +0200
images: New class wic-img for wic intregration
This patch integrates wic into the bitbake workflow, wic will be used
for the imaging step, no need to call it manually.
After all the previous reverts we now use an unmodified version of wic.
Issues:
- wic was never integrated
- you always had to build an ext4-img to create a wic image later
- there was never a way to control the size of wic disks/partition,
only directly in the wks
- wic used to leak the hosts bootloader into the final image
Impact:
The patch solves the Issues, but drops the ability to manually start
wic after bitbake. And it drops support for building wic images for
Distros before stretch.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Afterwards the code moved
> to image-tools-extension.bbclass with commit 0f9ae5bc. Between these
> changes I did not find any comments why it is restricting the usage.
>
> Quirin
>
>
>>
>> Am Tue, 23 Jul 2019 15:49:47 +0200
>> schrieb "[ext] Quirin Gylstorff" <quirin.gylstorff@siemens.com>:
>>
>>> The dependencies for wic are only added if IMAGE_TYPE
>>> is equal to "wic-img". If a image type depends on the
>>> wic-image class it is no longer possible to build a
>>> wic image.
>>>
>>> Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com>
>>> ---
>>> meta/classes/image-tools-extension.bbclass | 6 ------
>>> meta/classes/wic-img.bbclass | 4 ++++
>>> 2 files changed, 4 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/meta/classes/image-tools-extension.bbclass
>>> b/meta/classes/image-tools-extension.bbclass index b8672d5..ca94d49
>>> 100644 --- a/meta/classes/image-tools-extension.bbclass
>>> +++ b/meta/classes/image-tools-extension.bbclass
>>> @@ -14,12 +14,6 @@ IMAGER_INSTALL ??= ""
>>> IMAGER_BUILD_DEPS ??= ""
>>> DEPENDS += "${IMAGER_BUILD_DEPS}"
>>> -python () {
>>> - if d.getVar('IMAGE_TYPE', True) == 'wic-img':
>>> - d.appendVar('IMAGER_INSTALL',
>>> - ' ' + d.getVar('WIC_IMAGER_INSTALL', True))
>>> -}
>>> -
>>> do_install_imager_deps[depends] = "buildchroot-target:do_build"
>>> do_install_imager_deps[deptask] = "do_deploy_deb"
>>> do_install_imager_deps[lockfiles] += "${REPO_ISAR_DIR}/isar.lock"
>>> diff --git a/meta/classes/wic-img.bbclass
>>> b/meta/classes/wic-img.bbclass index 94f0b02..eee27b3 100644
>>> --- a/meta/classes/wic-img.bbclass
>>> +++ b/meta/classes/wic-img.bbclass
>>> @@ -11,6 +11,10 @@ do_copy_wks_template () {
>>> cp -f '${WKS_TEMPLATE_PATH}' '${WORKDIR}/${WKS_TEMPLATE_FILE}'
>>> }
>>> +
>>> +IMAGER_INSTALL = ${WIC_IMAGER_INSTALL}
>>> +
>>> +
>>> python () {
>>> import itertools
>>> import re
>>
>
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de
next prev parent reply other threads:[~2019-07-23 14:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-23 13:49 Quirin Gylstorff
2019-07-23 14:18 ` Henning Schild
2019-07-23 14:42 ` Quirin Gylstorff
2019-07-23 14:56 ` Claudius Heine [this message]
2019-07-23 15:15 ` Henning Schild
2019-07-23 15:24 ` Jan Kiszka
2019-07-23 15:04 ` [PATCH v2] " Quirin Gylstorff
2019-07-23 15:08 ` Claudius Heine
2019-07-25 10:20 ` [PATCH v3] " Quirin Gylstorff
2019-08-01 4:26 ` Baurzhan Ismagulov
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=a899e7d4-b697-804e-22bb-5875d3ae8f64@siemens.com \
--to=claudius.heine.ext@siemens.com \
--cc=henning.schild@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=quirin.gylstorff@siemens.com \
/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