Re: [RFC][PATCH 0/6] development vs. production builds

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

On Tue, 2017-05-16 at 14:49 +0300, Alexander Kanavin wrote:
> On 05/16/2017 11:21 AM, Patrick Ohly wrote:
> 
> >> While the "development/production" switch may be great for some projects,
> >> it'll make things only more complicated for others while gaining nothing above
> >> what we have now.
> >
> > What about the approach I outlined in my reponse to Richard, where we
> > just introduce the IMAGE_MODE mechanism in OE-core without defining
> > specific modes? Would you find that useful?
> 
> Please no. Global variables are a headache, and the less we have of them 
> the better.
>
> Here in particularly, what is wrong with defining:
> 
> patricks-awesome-image-developers.bb
> (containing IMAGE_FEATURE = "no-password-for-anything")
> 
> patricks-awesome-image-production.bb
> (containing IMAGE_FEATURE = "serious-security")
> 
> and the common bits can go to patricks-awesome-image.inc.

Then why is not already done like that in practice? Is it just because
OE-core and Poky set such a bad precedence with teaching developers to
add EXTRA_IMAGE_FEATURES ?= "debug-tweaks" to make the images usable,
and then that approach gets copied?

I think everyone agrees that removing "debug-tweaks" would be a good
idea. But completely removing the global (sic!) EXTRA_IMAGE_FEATURES in
local.conf.sample would go even further, and I am not sure how the
reactions to that would be. I suspect there are people who find it
useful to have just one image recipe that gets build in different
configurations (dangerous and not so dangerous).

Feel free to prepare and propose a patch that implements the idea above
for OE-core; I personally won't, I've had enough negative feedback for
this week already ;-}

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