[OE-core] Create more than one image with WIC

[Patrick Ohly]

On Wed, 2017-03-15 at 16:47 +0200, Ed Bartosh wrote:
> On Wed, Mar 15, 2017 at 04:01:43PM +0200, Ed Bartosh wrote:
> > On Wed, Mar 15, 2017 at 02:41:34PM +0100, Patrick Ohly wrote:
> > > On Wed, 2017-03-15 at 14:39 +0100, Patrick Ohly wrote:
> > > > On Wed, 2017-03-15 at 14:58 +0200, Ed Bartosh wrote:
> > > > > Regarding do_rm_work. It should not touch rootfs directories, I believe.
> > > > 
> > 
> > > It does, and it should by default because a rootfs can be quite large.
> > > If it's not going to be reused in another recipe, then it is worthwhile
> > > to remove it.
> > This is true unless we're going to use wic as a stand-alone tool, which some
> > people still do.
> > 
> > > I should add that RM_WORK_EXCLUDE_ITEMS += "rootfs" can be used in image
> > > recipes which know that their rootfs is going to be needed elsewhere -
> > > it's just not the default.
> > 
> > Isn't rootfs going to be rebuilt if one rootfs recipe depends on another one?
> 
> Here is an example of dependency I'm talking about:
> wic-image-minimal can be built just fine with enabled rm_work.
> Its .wks uses 2 rootfs: core-image-minimal and wic-image-minimal.
> 
> I didn't use any RM_WORK_EXCLUDE_ITEMS. I did specified dependency to
> core-image-minimal in wic-image-minimal recipe:
> 
> # core-image-minimal is referenced in .wks, so we need its rootfs
> # to be ready before our rootfs
> do_rootfs[depends] += "core-image-minimal:do_image core-image-minimal:do_rootfs_wicenv"
> 
> Am I missing something here?

I'm pretty sure you have a race condition, you just haven't triggered
the failure case.

Perhaps you were also lucky because my "rm_work.bbclass: re-enable
recursive do_rm_work_all" is pending and thus
core-image-minimal:do_rm_work never ran at all.

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