Re: update mechanisms

[Patrick Ohly <patrick.ohly@intel.com>]

On Mon, 2016-12-12 at 15:13 +0000, André Draszik wrote:
> Hi,
> 
> On Tue, 2016-12-06 at 10:45 +0100, Patrick Ohly wrote: 
> > I'll do the same for swupd. Editing the sections should be possible
> > without conflicts, we just have to be more careful about editing the
> > table concurrently.
> 
> It looks as if some highlights about swupdate can equally be said about
> swupd:
> 
> - dual copy is supported
> - my minimal swupd-based rescue initramfs is around 4MB

swupdate has support for a "dual copy
strategy" (http://sbabic.github.io/swupdate/swupdate.html#software-collections) while out-of-the-box (i.e. with what is currently available) meta-swupd and swupd itself don't. So I think it is correct to say that swupdate has some (implementation) advantage here.

The "could be extended to do updates without that risk" in the
"swupd/Failure resilience" section was meant to include a dual-copy
approach. Should that be rephrased to be more explicit? I was thinking
of several possible scenarios:
      * single partition: stage files, stop services, update, restart
        services or reboot
      * dual partition: update inactive partition, swap partitions,
        reboot

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.