Re: [RFC][PATCH 6/6] local.conf.sample: make debug-tweaks depend on IMAGE_MODE

[Patrick Ohly <patrick.ohly@intel.com>]

On Mon, 2017-05-15 at 13:25 -0700, Khem Raj wrote:
> On Mon, May 15, 2017 at 12:47 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> > The production image recipe "foobar-image-production.bb" can use
> > IMAGE_MODE_forcevariable = "production"
> > and the development image recipe "foobar-image-development.bb" can use
> > IMAGE_MODE_forcevariable = "development".

I'll probably automate the creation of these extra image variants via
BBCLASSEXTEND in an utility class. This seems to be of general
usefulness: base image with default IMAGE_MODE, one variant per valid
IMAGE_MODE where that mode is selected explicitly.

> > Then whatever the user might configure in local.conf is ignored in favor
> > of the fixed recipe values. If there's a concern about using
> > _forcevariable: that could be addressed by configuring a global
> > IMAGE_MODE_DEFAULT ??= "" and an IMAGE_MODE ??= "${IMAGE_MODE_DEFAULT}"
> > in image-mode.bbclass and changing IMAGE_MODE_DEFAULT in distro or local
> > conf. Then individual recipes can set IMAGE_MODE =
> > "development/production" without having to fall back to _forcevariable.
> >
> > Or do you mean that there's just one image .bb and traditionally
> > IMAGE_FEATURES were changed to switch back and forth? The same works
> > with IMAGE_MODE. The advantage over enabling or disabling dangerous
> > IMAGE_FEATURES is that users of a distro don't need to know about them.
> > They get the guarantee that (for a responsible distro) the dangerous
> > once will not get enabled by default for IMAGE_MODE=development.
> >
> 
> IMAGE_MODE is a distro settings not image setting is that correct ?

No, it is per-image. The code that checks the variable always runs in
individual image recipes.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.