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