Incremental builds based on presets

[malt3]

I noticed that presets in mkosi are roughly analogous to layers in a container image.
This makes me think that mkosi could have incremental builds on a preset level.
Let me explain the idea (in vague terms) before talking about how this could be implemented:

Idea

Let's say I have an multi-preset build like the one used by systemd:

• base holds packages, builds software and outputs a sysroot as a directory
• initrd generates a cpio used as initrd
• system depends on base, initrd and some extra trees (let's say a few tar files with software built elsewhere that can be used as extra trees) and generates a bootable uefi image with a uki

Now I perform one build.
If only one of the tar files for the system preset has changed, I want to be able to rebuild incrementally (keep base and initrd from the last build and only rebuild system).

Possible implementations

Let the user choose what needs to be rebuilt via command line parameters

This requires only a tiny code change but probably works well if used with existing build systems. The build system invoking mkosi would know what external dependencies a preset depends on and can tell mkosi what needs to be rebuilt.
All that is needed would be flags to either keep existing presets or to explicitly rebuild a list of presets. Mkosi should then rebuild all chosen presets and all of the presets that depend on the chosen presets.

Actually check all inputs for a preset and understand what has changed

This could be a lot of work in practice. Mkosi would essentially need to record all inputs for a preset (Trees, resolved packages, the exact configuration, probably more) and decide itself if a preset needs to be rebuilt. It would the need to rebuild the changed presets and all of the presets that depend on changed presets transitively.

Possible alternatives

You can define layers by having separate folders with their own mkosi config and let them depend on each other (by referencing the outputs from one directory in the basetree of another directory).
In this scenario, mkosi cannot by itself orchestrate the whole build and another build system needs to know that layers depend on each other and build layers in the correct order.

---

I think this would make mkosi an optimal build tool for systemd sysext and full os images.
It would provide a similar level of convenience as a Dockerfiles do for building containers. I also think implementing only the first option for now would already provide a lot of value.
I also noticed that this is somewhat related to #1756

[DaanDeMeyer]

Can you repost this as a comment in #1756 instead?

(My idea was to actually check all the inputs, yes that'd be a lot of work, but it's really the only way to do this properly).

Let's continue the discussion in #1756