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. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
