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

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

On Tue, 2017-05-16 at 08:29 +0100, Richard Purdie wrote:
> I'm not really sure I like this change, it seems fairly invasive and
> complex for gains which don't seem to add up to me.
> 
> For example after your patchset, we end up with two different places
> motd may be generated based on various flags. I think it would be
> confusing for the user to find out where a message as coming from.

Fair enough. I'm not a big fan of the "debug-build" DISTRO_FEATURES
either, and just included it as reference for what could be done at the
distro level.

What about just patch 4, the one which introduces image-mode.bbclass? Is
that of enough interest to carry it in OE-core? With or without enabling
it by default for images (patch 5)?

That classes currently defines three modes in IMAGE_MODE_VALID, but
intentionally with the weakest default possible. Distros can override
that to match their intended usage modes, or (better, now that I think
about it) we make the default empty and when users try to set IMAGE_MODE
(because they might have seen it in some other distro) they get an error
(assuming that we inherit the class in image.bbclass).

My concern with not having this class in OE-core is that each distro
will have to come up with their own way of doing something like this,
with no consistency between distros. That is going to confuse some
users. If a distro does not want this feature, they can just ignore the
class, once we make IMAGE_MODE_VALID empty by default.

> One of the reasons I have grown to hate "debug-tweaks" is that when you
> enable it, you have no idea what you're really changing as the name
> doesn't tell you what it does.

I'm fine with eliminating "debug-tweaks" entirely. In that case,
local.conf.sample should just list the individual features directly?

>  I worry "debug-build" will become the
> same problem, it doesn't do one thing well but many things badly. If it
> really just changes debug and logging PACKAGECONFIG (if present), why
> doesn't the distro just do that?

The idea was that the distro or user can set a global flag without
having to know all these details. For example, consider the case where a
user adds a custom recipe to a distro. If the distro has a
"development.inc" and "production.inc" with PACKAGECONFIGs that tune
recipes to match the intended usage, then those lists won't configure
the custom recipe. 

> I also worry about the number of classes this introduces. Whilst
> classes are cheap and easy, I have heard concerns we have too many of
> them. In this case image-mode gets hardcoded into image.bbclass.

We could merge the content of image-mode.bbclass also into
image.bbclass, if there is consensus that this code should be active by
default.

I've done it differently here because I wanted to have the ability to
use the standalone image-mode.bbclass in refkit.

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