Even more configuration rework🎉?

[septatrix]

I was looking at the changes as a result of #2847 and think is still potential to make configuration easier and more powerful at the same time.

It would be great to be able to directly configure some property of the subimage without modifying the main image. I was thinking something like --<image-name>.format=disk. This could unified together with the existing initrd/toolstree options without having to introduce longer and longer prefixes for them. E.g. instead of --tools-tree-package-manager-tree= use --tools-tree.package-manager-tree= and --initrd.package= can be used instead of --initrd-package=. This would make it easier to configure those images. E.g. --initrd.remove-packages= could be used instead of needing to create a config and using InitrdInclude=

I was also thinking about having something similar in the config files itself. Especially the configuration of the initrd but also the tools tree is somewhat limited by the available options (or at least made more cumbersome due to needing InitrdInclude=). A potential solution would be to extend the INI syntax to allow TOML-like section headers with a dot, e.g. [Initrd.Content]. This would allow easy configuration if the initrd without requiring InitrdInclude= or being limited by the amount of available Initrd*= passthrough options

[DaanDeMeyer]

@septatrix For the initrd you can now just add a subdirectory initrd under mkosi.images and have a mkosi.conf in there with as its first lines:

[Config]
Include=mkosi-initrd

We're already using this in systemd and I'm considering deprecating all the InitrdPackages= settings in such in favor of that. We'll keep the default initrd but we might remove the options to configure it in favor of extending it yourself via mkosi.images.

We don't actually want to make the default tools tree more configurable. We currently rely on the opposite since we don't rebuild it anymore on every build if we have a cached image of it available. This only works if all we do is install packages in it (with maybe a prepare script).

I'm not opposed to allowing subimage configuration like you proposed, although it would introduce even more complexity into the config parsing so there'd have to be some good use cases for it.

[septatrix]

The points regarding the initrd and reducing configuration options for the tools tree make sense to me.

I'm not opposed to allowing subimage configuration like you proposed, although it would introduce even more complexity into the config parsing so there'd have to be some good use cases for it.

Yeah the CLI parsing would likely become a bit more annoying as we now have dynamic options. I do not expect the parsing of the files to become much more complicated though.

[septatrix]

Another advantage btw would be to configure subimages in mkosi.profiles/ instead of creating separate config files and match sections for them.

[DaanDeMeyer]

Another advantage btw would be to configure subimages in mkosi.profiles/ instead of creating separate config files and match sections for them.

We also have Include= to share snippets between subimages

[septatrix]

I noticed that sub"images" are not suited for me anymore because they do not support most features which would be required for actual images.

However, my initial though would be to have e.g. a debug profile. This could then be simplified to

# mkosi.profiles/debug.conf
[kiosk.Content]
Packages=
    gdb
    valgrind
    wev

[headless.Content]
Packages=
    gdb
    valgrind
Ssh=yes

Instead of needing to create mkosi.images/kiosk/mkosi.conf.d/debug-profile.conf with a [Match] sections etc.
This also keeps everything relating to a profile together in a single place