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

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

On Wed, 2017-05-17 at 15:56 +0300, Alexander Kanavin wrote:
> On 05/17/2017 01:47 PM, Patrick Ohly wrote:
> 
> > 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.
> 
> I disagree that it doesn't scale. It scales just fine with a 
> well-constructed include files hierarchy. I'd even argue that's the only 
> way to stay sane when there's more than a few product configurations:

[...]

Now add one more mode and you end up with six instead of two image
recipes. That's what I consider not scalable.

> This pattern is used throughout openembedded. Take a look at machine or 
> distro configurations for example, or how both python 2 and 3 can be 
> supported with a single recipe include and two very short recipes in 
> meta-python. What does IMAGE_MODE do that include files cannot?

It does the same thing in a different way. What is preferred is
subjective.

I think we've both made our opinion clear. Let's hear from others.

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