[OE-core] [PATCH v2 1/1] image-mode.bbclass: common infrastructure for choosing image defaults

[Patrick Ohly]

On Wed, 2017-05-17 at 12:49 +0300, Alexander Kanavin wrote:
> On 05/17/2017 10:58 AM, Patrick Ohly wrote:
> > A distro might want to offer developers different, pre-defined ways of
> > building an image, for example a "development" mode with easy (but
> > insecure) login methods and a "production" mode with hardened
> > settings.
> 
> Apologies Patrick, I still think this brings more complication than 
> benefits. And it's not even showcased anywhere in poky: you add the 
> variable, but don't take it into use anywhere. Which means it also won't 
> get tested.
>
> You can do this thing by creating separate image recipes, each with 
> their hand picked IMAGE_FEATURES. And that includes showing appropriate 
> motd as well - but that perhaps would not be necessary because the image 
> mode would be encoded in its file name.

Can you be specific? Which image recipes should I add?

The feature by design is now meant to be used by distros. OE-core
doesn't contain a distro definition, so the feature cannot really be
used in OE-core in a realistic, reusable way. I can write a selftest
with a custom distro or image configuration, if that addresses your
concern about not getting the code tested.

I know that you prefer defining more image recipes over allowing the
reconfiguration of the same image recipe. I disagree on that, because
when you have independent aspects (like content and login
configuration), then you end up with various combinations of those
configuration options. Writing down all combinations in pre-defined
image recipes just doesn't scale. But you are welcome to proof me wrong
by showing how the existing image recipes in OE-core should be changed
so that they not only cover different content selection, but also what's
currently done via EXTRA_IMAGE_FEATURES in local.conf.sample.

-- 
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.