[OE-core] [PATCH 3/3] image_types_wic: Add variable WIC_EXTENSION

Ioan-Adrian Ratiu adrian.ratiu at ni.com
Tue Aug 28 09:17:39 UTC 2018


On Tue, 28 Aug 2018, Richard Purdie <richard.purdie at linuxfoundation.org> wrote:
> On Mon, 2018-08-27 at 17:31 +0300, Alexandru Vasiu wrote:
>> Used to specify what extention will have the image file which
>> is created using wic. The default value is wic. For creating an
>> ISO image, WIC_EXTENSION will be iso.
>> 
>> Signed-off-by: Alexandru Vasiu <alexandru.vasiu at ni.com>
>> ---
>>  meta/classes/image.bbclass           | 2 ++
>>  meta/classes/image_types_wic.bbclass | 3 ++-
>>  2 files changed, 4 insertions(+), 1 deletion(-)
>> 
>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
>> index 024d2d4c96..c6833a6770 100644
>> --- a/meta/classes/image.bbclass
>> +++ b/meta/classes/image.bbclass
>> @@ -607,6 +607,8 @@ python create_symlinks() {
>>      if not link_name:
>>          return
>>      for type in subimages:
>> +        if type == 'wic':
>> +            type = d.getVar('WIC_EXTENSION')
>>          dst = os.path.join(deploy_dir, link_name + "." + type)
>>          src = img_name + imgsuffix + type
>>          if os.path.exists(os.path.join(deploy_dir, src)):
>
> This is hardcoding an image type specific issue into common code. I
> really want to avoid doing that.
>
> In the past I started the process of trying to untangle the spaghetti
> we had in image.bbclass and abstract it into common building blocks.
> The hope was to eventually have proper APIs around this.
>
> I never really got back to do further rounds of cleanup/improvement to
> get to that goal but the more image type specific pieces we add back
> in, the harder it will make those goals and the less maintainable the
> coed will become.
>
> So is there some other way we can handle this. It looks like we don't
> even use this iso mode in OE-Core which is bad from a testing
> perspective too? I don't see WIC_EXTENSION being set to iso anywhere?

Our problem is this: all WIC images built & symlinked under
${DEPLOY_DIR_IMAGE} have the extension .wic, including the iso's.

We want our build pipeline to output an iso directly after issuing
"bitbake <image>" by adding IMAGE_FSTYPES += "wic" and having an
<image>.<machine>.wks which speficfies the isoimage-isohybrid plugin.

I agree this solution is hacky. An alternative would be to just rename
the image .wic extension to .iso in our piepline outside bitbake and be
done with it.

How about adding an IMAGE_FSTYPES += "iso" and creating the associated
logic/bbclasses? Is that amount of code justified to have .iso
extensions to wic-built images or are we better of just renaming .wic
to .iso?

>
> Cheers,
>
> Richard
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openembedded.org_mailman_listinfo_openembedded-2Dcore&d=DwICAg&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=fzwh7IUt7VYYiD6094geII0kSDP3DkEnN0B8zB62AxE&m=TX1s2gOuF5JVPXLJ60USSIym1ujQ2VDP00KcC-1c-_c&s=pYCCOX_mHEmd8jE8DN3zmrnoYuL35Wz_sA2MuuYDNrw&e=



More information about the Openembedded-core mailing list