could we possibly just have the ostree_installer phase config use the same layout as most of the other phases? i.e. a dict whose keys are variants and values are lists of dicts which specify arches and subvariants, like the image_build and live_media phases. this "list-of-2-tuples" approach is weirdly different and I at least find it hard to get my head around.

edit: to be clear the problematic design already exists, but this PR seems like an opportunity to change it. of course it's probably more disruptive.

Hm, that is an interesting idea. I like it. The list of arches would then either be inside the dict, or implicitly derived from variant architectures.

It would require ability to insert current architecture into the lorax template strings, but that doesn't seem complicated (or maybe it's possible with --add-arch-template-var, though I don't know how exactly that works).

It could look like this maybe?
https://pagure.io/fork/lsedlar/pungi-fedora/c/32e9a9416ff8f6c69e243e37f9a321c737245dad?branch=tentative-config-change

Is this what you have in mind?

I like that a lot. It seems much more sane and a lot less repetitive.
It could be done in a backwards compatible manner too (except for the arch interpolation, that could potentially conflict if someone is using the same syntax, which I very much doubt someone actually does).

And then when with all images merged under one variant:
https://pagure.io/fork/lsedlar/pungi-fedora/c/c85ae16999df735aa633ef247485594da3f599eb?branch=tentative-config-change (variant definition not included)

There may be a problem with having all the images in one variant though. The ISO is not the only output, there's also the boot configuration:
https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-40/compose/Kinoite/x86_64/os/
https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-40/compose/Onyx/x86_64/os/
https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-40/compose/Silverblue/x86_64/os/
If the images are in one variant, they are going to overwrite the files from other subvariants, and an arbitrary one will win. This should probably be somehow solved (some namespacing based on subvariant? not copying these files at all if subvariant is different from main variant? something else?)

The list of arches would then either be inside the dict, or implicitly derived from variant architectures.

Well, yeah, that's how it is for other phases. In both image_build and live_media phases, the lowest-level dicts describing the images themselves have arches keys. Indeed, even in the ostree phase, this is the design. AFAICS, ostree_installer is the only phase that does it this way, with tuples.

Is this what you have in mind?

Yup, pretty much. Is the 'templating' of the arch values like that possible? Maybe those being arch-specific was the reason it was designed this way?

If the images are in one variant, they are going to overwrite the files from other subvariants, and an arbitrary one will win. This should probably be somehow solved (some namespacing based on subvariant? not copying these files at all if subvariant is different from main variant? something else?)

Yeah, I see the issue. I guess the question is do we really want/need to ship that stuff for the Atomic Desktop variants. I believe it's there to support various somewhat 'unusual' install scenarios, like PXE installs and direct-kernel-boot installs. If supporting those is in scope, they might not want this design. I guess all we can do is ask them - I'll post back on the original ticket asking for input.

I kinda like your idea of "only copy the files if variant and subvariant match", though it would have to be clearly documented somewhere as it's kinda magic behaviour; that would allow us to still potentially have ostree installer variants where we do publish all that stuff, if we want to have them in a different context.

Also CCing @kevin , as he may be able to think of some other reason why we would or wouldn't need the boot configuration stuff.

I would defer to ostree experts, I am not really sure myself...

I don't think the question really relates to ostree payloads. IIUC, anyway. I think the question boils down to "what possibilities do we lose if we don't ship the os/ directory?", because that's waht we'd actually lose.