Re: [Openembedded-architecture] Incorporating deploy artefacts from one multiconfig in another multiconfig

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2019-02-21 at 20:09 -0500, Rich Persaud wrote:
> > On Feb 21, 2019, at 18:51, Richard Purdie <
> > richard.purdie@linuxfoundation.org> wrote:
> > 
> > Multiconfig is meant to support this workflow. Unfortunately there
> > are
> > open bugs and people haven't the time to work on it so its stalled.
> > That said, the key pieces are already there.
> > 
> > A picture is worth a thousand words. I thought a demo might
> > interest
> > people and "prove" this can work.
> 
> Thank you for the patches and PoC.  We will test and are motivated to
> see this work.

I've been thinking about what Alejandro and I discussed and I think the
correct fix for the multiconfig code is to filter the BB_TASKDEPDATA at
source in bitbake to remove the multiconfig entries for other
multiconfigs. I'll try and work up a patch for that in the next day or
two as the hacks on my branch that do this are fragile right now.

> I will also be experimenting with the generation of "immutable
> infrastructure" from source code, to learn whether a single Packer.io
> template can be used to both:
> 
> (a) modify binary images, in the traditional Packer model, e.g. start
> a bitbake-generated image in a VM or container, make runtime
> configuration changes, then repack the machine image
> 
> (b) perform automated customization  of _inputs_ to bitbake recipes
> and package source code, such that a machine image built by bitbake +
> Packer template is equivalent to the image generated by Packer at
> runtime
> 
> If feasible, this would combine the agility of image customizations
> with the security of bitbake's reproducible builds and supply chain
> integrity.

(a) definitely sounds easier than (b). I've not used packer.io but I'd
be curious to see how that works out. People do find our image
customisation hard to get to grips with :(

Cheers,

Richard