[OE-core] [PATCH 00/10] Integrate swupd software updater

[Joshua G Lock]

On Wed, 2016-02-24 at 16:37 +0100, Patrick Ohly wrote:
> Hello!
> 
> I haven't had a chance to play with the actual code yet and I don't
> know
> yet when I'll be able to. Let me ask for some clarifications about
> the
> approach first anyway.
> 
> On Wed, 2016-02-24 at 14:52 +0000, Joshua Lock wrote:
> > 
> > Approach:
> > An image that inherits the swupd-image bbclass will automatically
> > have bundle
> > 'chroots' created which contain the filesystem contents of the
> > specified
> > bundles, with the contents of the inheriting image forming the
> > default os-core
> > bundle.
> > 
> > The mechanism to achieve this is that several virtual image recipes
> > are created
> > using the swupdbundle class, one for each defined bundle plus a
> > 'mega' image
> > recipe. The 'mega' image contains the base image plus the contents
> > of all of the
> > bundles, whilst bundle images contain only the base image plus the
> > contents of a
> > single bundle.
> Just to be sure, the actual "content" (a term that is a bit too
> overloaded to be used precisely in all cases) of a file and its meta
> attributes will come from the mega image, and the virtual image
> recipes,
> including the base image, are merely used to generate file lists?

That's not currently true, no — the file contents for a bundle come
from the bundle image and the file contents for os-core come from the
base image. It shouldn't be too difficult a change to make, I'll take a
look now.

> What is the content of the actual image that gets created? It has to
> match the content (= file content and meta information) of the mega
> image and not of the base image, otherwise there can be
> inconsistencies
> between the actual running image and the core os bundle. I suppose
> swupd
> will be able to fix that, but I'm not sure.
> 
> It sounds like this bundle creation is completely separated from the
> regular image creation; if so, then I suspect that this may have to
> change.

Right, currently bundle creation happens after image creation and as
above bundles are populated from the rootfs of the bundle images.

You're right, of course, we'll need to construct the running image from
the bundle contents for more complex images.

> > 
> > We took the approach of building images, rather than populating the
> > chroot-like
> > bundle directories with a package manager, because various layers
> > and recipes
> > make changes to the rootfs contents outside of the package manager,
> > particularly
> > with IMAGE_POSTPROCESS_COMMAND, etc.
> Makes sense to me.
> 
> Have you considered generating the file lists more efficiently? I can
> think of some alternatives, but all have downsides.
> 

I did consider a couple of other approaches but with a goal of
submitting this for M3 this approach felt like the surest route within
the time available. I'd certainly like to find a more efficient method
and if you have any suggestions I'd be happy to hear them.

Regards,

Joshua