Re: Usage of yocto on different (production vs debug) scenarios

[Uwe Geuder <jrswdnan22@snkmail.com>]

Hi!

On Fri, Apr 20, 2018 at 10:59 AM, Iván Castell <icastell@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@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?
> 
>