Re: [RFC] Image templates

[Claudius Heine <ch@denx.de>]

Hi Cedric,

On 2020-12-01 08:59, Cedric Hombourger wrote:
> Image Templates for ISAR
> ========================
> 
> Introduction
> ------------
> 
> Embedded System projects may have multiple teams working at different 
> levels. It is not uncommon to have groups creating a "base platform" 
> which is handed over to product teams to customize further.
> Thanks to ISAR leveraging bitbake, image recipes from a base layer may 
> be easily extended by product layers but also with its ability to 
> produce and use a `base-apt` instead of upstream package feeds.
> This workflow functions well in many cases, it may not be optimal for 
> application teams. Such teams are typically receiving a base platform 
> release that is likely to be left untouched for weeks.
> Creating a product image for those teams is sometimes as easy as adding 
> a few packages.
> 
> In such cases, it may be desirable to have a mechanism for ISAR to 
> construct product images starting from the base platform root 
> file-system instead of ISAR's bootstrap root file-system. We will refer
> to these base platform root file-systems as _Template Images_.

In principle I understand your requirement, however I don't think Isar 
(and possible Debian) is the right base for this.

What you probably require is some sort of functional and non-destructive 
root-fs build approach to root file system, that lets you arbitrarily 
cache and distribute each stage of the root fs build. Generating and 
reusing the 'base-apt' repository is much easier than it would be for 
root file systems.

Also stuff like docker solves only a small part of that solution.

You will probably have to build a new system inspired by stuff like the 
bazel build system[1], and nixox[2] or guixos[3] and maybe even stuff 
like ostree [4].

The rest of what you describe sounds like they would try to shoehorn 
this into the existing isar build process and then trying to explicitly 
fix just some of the many future issues you will run into, instead of 
actually designing something that is actually able to deal with all 
those issues in a generic way.

Personally, I would be interested in such a new system, but that will 
take serious dedication to design and implement it properly.

Changing that now in Isar will probably break a lot of assumptions and 
therefore limit its usefulness.

This suggestions reminds me a bit as the eSDK of OE, where I still 
couldn't really find a use for and from my experience creates more 
issues than it actually solves.

regards,
Claudius

[1] https://www.bazel.build/
[2] https://nixos.org/
[3] https://guix.gnu.org/
[4] https://ostreedev.github.io/ostree/introduction/