[yocto] update mechanisms

[Patrick Ohly]

On Mon, 2016-12-12 at 09:49 -0600, Mariano Lopez wrote:
> 
> On 12/12/16 09:41, Patrick Ohly wrote:
> > On Mon, 2016-12-12 at 08:59 -0600, Mariano Lopez wrote:
> >>>> In particular the "complexity" column is a bit subjective. Stefano, I
> >>>> hope you don't mind that I did not quite buy the "easy to use"
> >>>> characterization of swupdate ;-)
> >>> No worry...and I have not written myself. It was inserted by Mariano, so
> >>> it looks like that swupdate at least for Mariano is "easy to use".
> >>> I think it is correct to point out that customization is required.
> >> Compared to other update mechanism that I tested it was the easier to
> >> implement.
> > Which "getting started" document or presentation were you using? The
> > documentation for mender (https://docs.mender.io/) is very
> > straight-forward (partly of course because it doesn't need to cover many
> > variations), while for swupdate
> > (http://sbabic.github.io/swupdate/swupdate.html) I found it less clear
> > how to begin.
> >
> 
> When I did a research in update mechanism, mender wasn't yet available,
> and indeed it seems very straight forward (need to test it before final
> veredict). But if you compare SWUpdate, swupd, and OSTree; SWUpdate is
> by far less complex than the other two

Ease-of-use is not necessarily determined by the complexity. Good
integration and documentation can go a long way towards making a complex
solution easy to use - when sticking to the pre-defined usage patterns.

The opposite is also true: a simple solution may be hard to use if all
one gets is the source code and one first has to reverse-engineer the
usage model.

I agree that the complexity is roughly swupdate < ostree < swupd and
there's also no doubt that the latter two aren't easy to use (mostly due
to lacking documentation and integration), but I'm still not sure what
documentation the "easy to use" verdict for swupdate is based on.

-- 
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.