> On Feb 22, 2019, at 02:35, Richard Purdie
> <[email protected]> wrote:
>
> On Thu, 2019-02-21 at 20:09 -0500, Rich Persaud wrote:
>>> On Feb 21, 2019, at 18:51, Richard Purdie <
>>> [email protected]> 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.
Looks like the patches are in bitbake 1.40.
Is it possible to avoid duplicate builds of packages which are used in multiple
VM images? Could multiconfig replace a dozen serial instances of bitbake with a
single parsing instance, or would it use a dozen parallel instances? If the
latter, is this a constraint in bitbake architecture, recipe DSL, or
time/resources?
>> 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 :(
Siemens 'kas' provides a declarative front-end for bitbake configuration, a
small step in the direction of (b):
https://kas.readthedocs.io/en/0.19.0/userguide.html#use-cases
https://github.com/siemens/kas
https://groups.google.com/forum/#!forum/kas-devel
Rich
_______________________________________________
Openembedded-architecture mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
