Re: [meta-ota][PATCH] meta-ota: add support for binary-delta images in a new layer

[Khem Raj <raj.khem@gmail.com>]

On 3/2/20 9:39 AM, Bartosz Golaszewski wrote:
> pon., 2 mar 2020 o 12:25 Otavio Salvador
> <otavio.salvador@ossystems.com.br> napisał(a):
>>
>> On Mon, Mar 2, 2020 at 4:37 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>> niedz., 1 mar 2020 o 14:43 Otavio Salvador
>>> <otavio.salvador@ossystems.com.br> napisał(a):
>>> This single class surely doesn't justify a new layer but I have a
>>> bunch of other stuff lined up for upstreaming if this is accepted.
>>> This is thematically separate from most of the recipes in meta-oe too.
>>
>> So please give us an idea of what are your plans, so we can understand
>> it better.
>>
> 
> Sure. Next steps would be:
> 
> - Adding a class for generating provisioning partition images.
> Basically allowing to split parts of the rootfs into separate ext4 (or
> other) image similar to what meta-mender does in its mender-dataimg
> class for /data but generalized for configurable directories.
> 
> - Adding an image recipe for a factory reset system, where we would
> store the provisioning rootfs on a read-only partition together with
> an initramfs the role of which would be to reflash the A/B partitions
> to bring the device to a known state, this is something we do a lot in
> our consulting work.
> 
> - Adding standardized target-side scripts for applying binary-delta
> images. This uses the fact that many OTA frameworks support extensions
> to their client programs. For instance the same script could be used
> for applying the vcdiff and rsync patches both as a mender update
> module and a rauc handler (with a thin compatibility layer in their
> respective OE layers).
> 
> It still doesn't exhaust the subject but I think this really makes
> sense in a separate layer than being sprinkled all-over meta-oe.
> 
> Khem, Armin: any thoughts?

there are many ota layers on OE, most of them are self-contained, so a 
question arises, how is this different, somethings here say it could be 
a base layer for all OTAs, which actually seems quite valuable, but it 
has to be such that the existing OTA layers start using pieces from this 
layer, Other part seems to be that its yet another OTA using binary 
delta update techniques, so in such a case, it should be thought of as 
another OTA and perhaps maintained independendently, if there are 
features which are common across all OTAs we can host them in core or 
meta-oe,

> 
> Bart
>