<div dir="ltr">Sure, sounds good. <br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 1, 2018 at 2:03 PM Richard Purdie <<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 2018-10-01 at 11:12 +0000, Martin Jansa wrote:<br>
> * currently it's used only by image.bbclass, image_types.bbclass and<br>
> meta/recipes-core/images/<a href="http://build-appliance-image_15.0.0.bb" rel="noreferrer" target="_blank">build-appliance-image_15.0.0.bb</a><br>
> but if it's needed by some recipe which isn't itself an image, then<br>
> it's useful in bitbake.conf, e.g. we have a recipe for creating<br>
> VirtualBox appliances which combines .wic.vmdk with .ovf file to<br>
> create .zip with appliance, but for that we need the filename of<br>
> .wic.vmdk which now contains IMAGE_NAME_SUFFIX<br>
> <a href="https://github.com/webOS-ports/meta-webos-ports/blob/4980ce52a43ac6" rel="noreferrer" target="_blank">https://github.com/webOS-ports/meta-webos-ports/blob/4980ce52a43ac6</a><br>
> 897657602810313af359f0b839/meta-luneos/recipes-core/images/luneos-<br>
> emulator-appliance.inc#L24<br>
> <br>
> * we were hardcoding .rootfs suffix where needed, but for quite long<br>
> time it's configurable with IMAGE_NAME_SUFFIX and might not match:<br>
> <br>
> commit 380ee36811939d947024bf78de907e3c071b834f<br>
> Author: Patrick Ohly <<a href="mailto:patrick.ohly@intel.com" target="_blank">patrick.ohly@intel.com</a>><br>
> Date: Mon Mar 7 18:07:52 2016 +0100<br>
> <br>
> image creation: allow overriding .rootfs suffix<br>
> <br>
> Signed-off-by: Martin Jansa <<a href="mailto:Martin.Jansa@gmail.com" target="_blank">Martin.Jansa@gmail.com</a>><br>
> ---<br>
> meta/classes/image_types.bbclass | 6 ------<br>
> meta/conf/bitbake.conf | 6 ++++++<br>
> 2 files changed, 6 insertions(+), 6 deletions(-)<br>
<br>
You could make this argument for many of the class variables, with<br>
other code needing some small piece and we end up importing a ton of<br>
stuff into bitbake.conf and global scope. My worry is this isn't<br>
scalable and leads to code which is hard to disentangle.<br>
<br>
How about we create imagevars.conf which the class could include, or<br>
other users could include without pulling in the main class?<br>
<br>
Cheers,<br>
<br>
Richard<br>
<br>
<br>
</blockquote></div>