On Thu, 2019-02-21 at 20:09 -0500, Rich Persaud wrote: > > On Feb 21, 2019, at 18:51, Richard Purdie < > > richard.pur...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core