[OE-core] [PATCH] bitbake.conf: move IMAGE_NAME_SUFFIX variable from image_types.bbclass

[Martin Jansa]

Sure, sounds good.

On Mon, Oct 1, 2018 at 2:03 PM Richard Purdie <
richard.purdie at linuxfoundation.org> wrote:

> On Mon, 2018-10-01 at 11:12 +0000, Martin Jansa wrote:
> > * currently it's used only by image.bbclass, image_types.bbclass and
> >   meta/recipes-core/images/build-appliance-image_15.0.0.bb
> >   but if it's needed by some recipe which isn't itself an image, then
> >   it's useful in bitbake.conf, e.g. we have a recipe for creating
> >   VirtualBox appliances which combines .wic.vmdk with .ovf file to
> >   create .zip with appliance, but for that we need the filename of
> >   .wic.vmdk which now contains IMAGE_NAME_SUFFIX
> >   https://github.com/webOS-ports/meta-webos-ports/blob/4980ce52a43ac6
> > 897657602810313af359f0b839/meta-luneos/recipes-core/images/luneos-
> > emulator-appliance.inc#L24
> >
> > * we were hardcoding .rootfs suffix where needed, but for quite long
> >   time it's configurable with IMAGE_NAME_SUFFIX and might not match:
> >
> >   commit 380ee36811939d947024bf78de907e3c071b834f
> >   Author: Patrick Ohly <patrick.ohly at intel.com>
> >   Date:   Mon Mar 7 18:07:52 2016 +0100
> >
> >     image creation: allow overriding .rootfs suffix
> >
> > Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> > ---
> >  meta/classes/image_types.bbclass | 6 ------
> >  meta/conf/bitbake.conf           | 6 ++++++
> >  2 files changed, 6 insertions(+), 6 deletions(-)
>
> You could make this argument for many of the class variables, with
> other code needing some small piece and we end up importing a ton of
> stuff into bitbake.conf and global scope. My worry is this isn't
> scalable and leads to code which is hard to disentangle.
>
> How about we create imagevars.conf which the class could include, or
> other users could include without pulling in the main class?
>
> Cheers,
>
> Richard
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20181001/356abb0d/attachment-0002.html>