bundle.bbclass: split for a generic bundle-base.bbclass

[Louson]

Hello,

This is a suggestion for having a generic bundle-base.bbclass to keep essential functionalities unrelated to packaging concerns. So far the class inherits from nopackages and leaves no possibility for packaging or imaging.

This suggestion aims to not modify the usage of the bundle.bbclass but gives the ability to inherits only bundle-base.bbclass.

The goal for us next to this is to enable a raucb extension for images which would simplify the creation of images and associated bundles into a single recipe.

This could also allow having a packaged bundle which can be useful in case you want to embed the bundle into a live image.

Thanks

[jluebbe]

This is a suggestion for having a generic bundle-base.bbclass to keep essential functionalities unrelated to packaging concerns. So far the class inherits from nopackages and leaves no possibility for packaging or imaging.

This suggestion aims to not modify the usage of the bundle.bbclass but gives the ability to inherits only bundle-base.bbclass.

The goal for us next to this is to enable a raucb extension for images which would simplify the creation of images and associated bundles into a single recipe.

This would only work for the simple case where the bundle contains just the rootfs (no bootloader, no FIT image, no artifacts). With CRA, I suspect that most real-world systems will use secure/verified boot in some way and accordingly need multiple images in the bundle.

While it simplifies the simple case, supporting both approaches (bundle recipe and image type) would mean documenting them and explaining which to use in which case. Especially for new users, selecting the appropriate approach would a hard.

This could also allow having a packaged bundle which can be useful in case you want to embed the bundle into a live image.

You mean for an installer image, which then runs 'rauc install'? I think this can already be done via a rootfs postinstall function, which avoids the build-time overhead of creating/installing a huge package.

[Louson]

This is a suggestion for having a generic bundle-base.bbclass to keep essential functionalities unrelated to packaging concerns. So far the class inherits from nopackages and leaves no possibility for packaging or imaging.
This suggestion aims to not modify the usage of the bundle.bbclass but gives the ability to inherits only bundle-base.bbclass.
The goal for us next to this is to enable a raucb extension for images which would simplify the creation of images and associated bundles into a single recipe.

This would only work for the simple case where the bundle contains just the rootfs (no bootloader, no FIT image, no artifacts). With CRA, I suspect that most real-world systems will use secure/verified boot in some way and accordingly need multiple images in the bundle.

I agree with the CRA and my option is actually to get closer to the construction of the wic. They are quite similar and it would make sense to build them together from the image recipe. As for the wic, there no reason to restrict to the rootfs.

While it simplifies the simple case, supporting both approaches (bundle recipe and image type) would mean documenting them and explaining which to use in which case. Especially for new users, selecting the appropriate approach would a hard.

I can understand that. Meanwhile, people also do not understand they have to build the bundle separately while it is actually the same image. The wic is not perfect but it's quite simple isn't it ?

This could also allow having a packaged bundle which can be useful in case you want to embed the bundle into a live image.

You mean for an installer image, which then runs 'rauc install'? I think this can already be done via a rootfs postinstall function, which avoids the build-time overhead of creating/installing a huge package.

That's correct except the size of the rootfs won't be calculated automatically, would it ? That's not a serious issue though.

[ejoerns]

I can understand that. Meanwhile, people also do not understand they have to build the bundle separately while it is actually the same image. The wic is not perfect but it's quite simple isn't it ?

I can understand that having a way to generate bundles from the rootfs might feel some kind of 'natural' for those familiar with the current image creation/wic workflow OE has. However, I share the same concerns as @jluebbe.

The key advantage is of course to have fewer recipe files since otherwise you would need a corresponding bundle recipe for each rootfs recipe.

On the other hand, having a separate recipe for each and every package and all the options for defining dependencies between them makes it quite hard for me to understand why for disk image (or bundle) creation the best solution should be to 'just do it all between the do_image and do_image_compete task of the same recipe'.
And it becomes absurd when trying to build bundles that don't even contain a rootfs, which is a quite common case, either for bootloader updates, for appfs updates, or for artifact updates in the future.

So in the end as @jluebbe said, we optimize for a very simplified case. It's clear to me that simple problems my deserve simple solutions but I am quite unsure how much impact this should have on the common case and if that's worth doing such an invasive change that will surely make it much harder to backport future fixes, etc.

That's correct except the size of the rootfs won't be calculated automatically, would it ? That's not a serious issue though.

If you refer to ROOTFS_SIZE and what can be tweaked by IMAGE_ROOTFS_MAXSIZE etc. this is executed as the
set_image_size prefunc of the do_image_* task. Thus after rootfs creation and rootfs postprocess etc.

Just a side-note while looking at the patches: From your first commit:

Change how dependencies are handled by default. So far, do_bundle is set after
do_configure which is not in the default schedule. Instead, schedule it after
prepare_recipe_sysroot and schedule the do_configure before it.

That's clearly wrong since do_configure is defined in base.bbclass. What you mean here is that it is set to [noexec] in image.bbclass maybe?

[Louson]

I can understand that. Meanwhile, people also do not understand they have to build the bundle separately while it is actually the same image. The wic is not perfect but it's quite simple isn't it ?

I can understand that having a way to generate bundles from the rootfs might feel some kind of 'natural' for those familiar with the current image creation/wic workflow OE has. However, I share the same concerns as @jluebbe.

The key advantage is of course to have fewer recipe files since otherwise you would need a corresponding bundle recipe for each rootfs recipe.

On the other hand, having a separate recipe for each and every package and all the options for defining dependencies between them makes it quite hard for me to understand why for disk image (or bundle) creation the best solution should be to 'just do it all between the do_image and do_image_compete task of the same recipe'. And it becomes absurd when trying to build bundles that don't even contain a rootfs, which is a quite common case, either for bootloader updates, for appfs updates, or for artifact updates in the future.

So in the end as @jluebbe said, we optimize for a very simplified case. It's clear to me that simple problems my deserve simple solutions but I am quite unsure how much impact this should have on the common case and if that's worth doing such an invasive change that will surely make it much harder to backport future fixes, etc.

That's correct except the size of the rootfs won't be calculated automatically, would it ? That's not a serious issue though.

If you refer to ROOTFS_SIZE and what can be tweaked by IMAGE_ROOTFS_MAXSIZE etc. this is executed as the set_image_size prefunc of the do_image_* task. Thus after rootfs creation and rootfs postprocess etc.

I'm fine with your answers, it's probably better to keep it simple as long as there is no issue. Thanks for your time :)

Just a side-note while looking at the patches: From your first commit:

Change how dependencies are handled by default. So far, do_bundle is set after
do_configure which is not in the default schedule. Instead, schedule it after
prepare_recipe_sysroot and schedule the do_configure before it.

That's clearly wrong since do_configure is defined in base.bbclass. What you mean here is that it is set to [noexec] in image.bbclass maybe?

I'm not sure why I've written that. I think during my tests I met some case where do_configure was not a dependant task of do_build but I can't reproduce it right now.