[OE-core] [RFC PATCH 0/2] image.bbclass: support two-stage deployment of image artifacts

[Richard Purdie]

On Thu, 2020-03-19 at 19:20 +0100, Bartosz Golaszewski wrote:
> If we'll really get to a point where we need to create a hierarchy of
> multiple levels of image deployment, then maybe we should switch to
> deploying each image right after it is created in its dedicated
> do_image_<type> task, then we could really fine-tune the inter-task
> dependencies. But we're not there yet and IMO currently it would be
> overkill. The rule of thumb for me is not to add new interfaces
> nobody asks for.

Going back in time I'm the person who split the image pieces off from
do_rootfs and split the different image commands into different tasks.
I did this for several reasons but one was we were developing new task
dependency code inside the image construction which was just crazy.

I was wondering about the option of having the image task deploy the
image earlier. I think that could be made to work. I think conceptually
it makes more sense architecturally than adding in arbitrary new task
levels to the existing structure.

> This also makes your argument about adding a third category purely
> theoretical: I don't see how we would need another category of images
> anytime soon.

I often think things like that but then new use cases come along...

> Please do - I'm open for other ideas. Just please keep in mind:
> there's obviously a problem with the current approach. I described it
> in detail and it turned out Quentin had encountered it too and dealt
> with it using a nasty workaround (fitImage deployed by the image
> recipe and not the kernel). I'd like to fix it upstream and proposed
> a solution that is IMO not horrible. I'd appreciate if we could reach
> a compromise that wouldn't leave us with downstream hacks.

I do understand there is a problem. We also have problems with people
not understanding the code as it works today. Your proposal adds
something else with is hard to explain to users ("Is my image simple or
composed?") and whilst we can and do add complexity where we need to,
I'm not yet convinced this change makes enough sense to have it.

Changing the way image deployment works would in many ways be much
easier for people to understand and makes the system more flexible
without adding problematic terminology.

> Please also note that sometimes "gets the job done" really is better
> than not solving problems. Just look at initcall levels in the linux
> kernel - they are similar to what I proposed here and serve as a
> surrogate for real dependencies.

We have piles of "get the job done" and also need to sometimes take a
step back and see if we can do something better. Right now I think your
proposal makes things worse and will be hard to explain to people. My
instinct is we can do better here.

Cheers,

Richard