Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
	Alexandru Vasiu <alexandru.vasiu@ni.com>,
	openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 3/3] image_types_wic: Add variable WIC_EXTENSION
Date: Tue, 28 Aug 2018 12:17:39 +0300	[thread overview]
Message-ID: <874lfeu9xo.fsf@ni.com> (raw)
In-Reply-To: <5e5a13cb317d319f7ab9cb2a149881cd0adaa5d9.camel@linuxfoundation.org>

On Tue, 28 Aug 2018, Richard Purdie <richard.purdie@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@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@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=


      reply	other threads:[~2018-08-28  9:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-27 14:31 [PATCH 1/3] isoimage-isohybrid: Fix creating initrd.cpio Alexandru Vasiu
2018-08-27 14:31 ` [PATCH 2/3] isoimage-isohybrid: Fix variable names Alexandru Vasiu
2018-08-27 14:31 ` [PATCH 3/3] image_types_wic: Add variable WIC_EXTENSION Alexandru Vasiu
2018-08-27 23:00   ` Richard Purdie
2018-08-28  9:17     ` Ioan-Adrian Ratiu [this message]

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=874lfeu9xo.fsf@ni.com \
    --to=adrian.ratiu@ni.com \
    --cc=alexandru.vasiu@ni.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    /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