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

[Patrick Ohly]

On Wed, 2016-02-24 at 16:09 +0000, Lock, Joshua G wrote:
> 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.

The prime example that needs to be handled correctly is where installing
additional packages for one of the extra bundles adds a system user
to /etc/passwd (*). The content of /etc/passwd must come from the mega
rootfs.

(*) Except that swupd assumes that the distro is stateless and thus
automatically excludes /etc from bundles. The example is still valid
because preparing bundles does not need to care about that.

> > 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 can remove the original do_rootfs and do_image and replace it with
code that copies the relevant subset of the mega image. Then the rest of
the image creation will see the right content.

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

I don't have any and thus agree with this route. I was merely wondering
whether you already had a working solution in mind.

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