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

Patrick Ohly patrick.ohly at intel.com
Wed Feb 24 15:37:55 UTC 2016


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?

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.

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

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






More information about the Openembedded-core mailing list