I think good idea would be to automatically add -multilib profiles which would install both, otherwise only primary arch will be taken.

Just my 5 cents.

I think -multilib introduces another parsing problem/work.

In short: nope.

Unlike artifacts, profiles are defined by the module author before the actual NEVRAs are known. Even if they could be predicted (which they cannot be), this would require the author to update the entire list every time they update the module. I understand your concern but this is not the place to address it.

While we still need to support multilb, it's not our primary use case. I would learn towards proposing a policy that multilib simply isn't installed by default (profiles are all about default installation, nothing else) and only when the end user requests it specifically or when it's pulled in as a package dependency.

Also regarding versions, while it might be technically possible to smuggle multiple versions of the same name into one module with a specifically crafted SPEC file, the current pungi implementation would include only the latest package in the compose. And even if it didn't, this would kinda violate the spirit of modular packaging; I don't think we need to worry about such edge cases.

Each module build contains exactly one version of each binary package.

How about modifying profiles with artifacts? What I mean is you modify profiles after you know the actual NEVRAs, which is at the moment when you populate artifacts. This way there won't be problem with multilib. And user could specify it by appending -multilib as Igor suggested.

If you have logic that can automatically convert names in profiles to NEVRAs, you can have exactly the same logic in dnf. I fail to see the point here. Furthermore, one of the features of modulemd is the ability of taking the final modulemd file, submitting it again and getting exactly the same output, or something as close as possible. This would require further modifications in the chain.

Rather than having generated -multilib profiles, you could simply control this with a CLI or configuration option. There's no value in generating the information in pungi & storing it over generating the same data in dnf on the fly.

How exactly should I control multilib with CLI or config options? I can't imagine this. Can you explain it to me?

@mhatina tl;dr you don't install multilib packages unless it is dependency of something

If you had autogenerated -multilib profiles which would just include multilib of everything in the original non-multilib profile, you easily generate such a profile on the fly if the user supplies an option denoting they wish to install that profile in a multilib manner. It's exactly the same thing pungi would be doing when generating such additional profiles.

We might be having some misunderstanding about what parts of the file are filled in by the author and what parts are generated by the build pipeline. If you still find this confusing, we could sync "offline".