[yocto] Usage of yocto on different (production vs debug) scenarios

[Alan Martinovic]

Hi,
had a similar question recently (search How did you separate release
and development builds?)

We have the split like this for now
The release build would be something like:

- has all the functions for production
- attack surface is limited (no ssh, only the required apps)
- config files set with real endpoints (logging or crash servers etc.)

But that's not an image you can really develop on given all the constrains.
So there is also a need for a development image:

- inherits the functions available on production image + debug tools
- developer continence over security (debuggers, ssh access etc.)
- configs set not to depend on payed cloud services

Both are built as a same distro, but are different images.

So far it works ok.
However still haven't experienced the need to have different
configurations for the same recipe, that would probably complicate things.


On Fri, Apr 20, 2018 at 12:47 PM, Uwe Geuder <jrswdnan22 at snkmail.com> wrote:
> Hi!
>
> On Fri, Apr 20, 2018 at 10:59 AM, Iván Castell <icastell at nayarsystems.com> wrote:
>
>> We are trying to use yocto in a continuous integration environment with
>> different (production vs debug) scenarios.
>>
>> To setup a given scenario (production vs debug) we are using something like
>> this:
>>
>>     $ SCENARIO=debug
>>     $ MACHINE=<machine> DISTRO=<distro>-${SCENARIO} source
>> ../../build-<machine>-${SCENARIO}
>>     $ bitbake <image>-${SCENARIO}
>>
>> So we have different image recipes:
>>
>>     * image-production.bb
>>     * image-debug.bb
>>
>> Different distros:
>>
>>     * distro-production.conf
>>     * distro-debug.conf
>>
>> And different build directories:
>>
>>     * build-<machine>-production
>>     * build-<machine>-debug
>>
>> To optimize space usage and compilation time, we setup a shared sstate
>> cache and a shared directory for downloads. This seems a good starting
>> point.
>
> Shared download, yes.
>
> But can you share state between distros? Isn't the purpose of distros to
> use different options (variable settings) so the state would always be
> different?
>
> (Please note: This is really a follow-up question, not me knowing
> better. I am just trying to fully understand these concepts)
>
>
>> However, things are getting complicated, because there is no way to
>> exclude some recipes easily. For example, we don't want iptables
>> installed on the debug image, but dependency chains include iptables
>> by default
>
> Doesn't blacklist do what you want?
>
> E.g. in your distro-production.conf
>
> PNBLACKLIST[iptables] = "we don't want iptables in product"
>
>
> Of course if something has a hard dependency on iptables, the something
> might need blacklisting instead or too.
>
>
> Regards,
>
> Uwe Geuder
> Neuro Event Labs Oy
> Tampere, Finland
> uwe.gexder at neuroeventlabs.com (Bot check: fix one obvious typo)
>
>
>
>
>> even when declaring IMAGE_INSTALL_remove explicitly. In this case we
>> decided checking _%.bbappend to decide what rules are installed on ion
>> vs rules.debug).
>>
>> hod is poisoning all our recipes with that kind of
>>
>>
>>  right way to manage this? Can you suggest a
>> ay to deal with this?
>>
>>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto