Yes, this is a generic problem we were previously going to solve by simply making such modules conflict (e.g. by adding conflicts to module-build-macros). In the hybrid world we cannot really do anything like that... or can we?

The base virtual modules are already special (see e.g. https://pagure.io/fm-orchestrator/issue/830). Perhaps we could update module-build-macros after each build group, adding conflicts with everything besides the NEVRs that just got built?

Anyway, I consider this a high priority.

The conflicts should take into account binary packages that comes from build-required modules other than platform. E.g. I want to use perl package from perl-bootstrap module when building perl package into perl module. I.e. we should enumerate all binary packages from build-required modules, plus all already built packages from currently being built module. Then check if they exist in platform module, and if they do, then conflict to their platform NEVRAs.

The implementation of this REF mostly depends on a way how we will fix #830. I kind of like solution described by @ppisar, but since we don't know how we are going to get the platform into the buildroot, it is not clear from where we should take the list of current packages to conflict with (should we get it from tag or from external repo generated based on that tag?)

I was just checking how Koji generates the repository in our case with platform as external repo.

It seems it generates local repository from modular koji tags (it means non-external repositories) and then calls "merge_repo_c ./local_repo external_repo1 external_repo2 ..." and so on. In case some package is in multiple repositories, it takes the one with highest NVR. But we would need it to always take the one from the first repo (modular one) in this case.

Changing that would be hard, because we would need to patch mergerepo_c...

So, Koji change is probably not a way to go and we should really try what @ppisar describes.

When implementing it, please also consider packages provided by modules that are recursive run-time dependencies of the build-requires modules.

Koji creates repo for all tagged RPMs and then merges with external repo. When merging repos, tag repo takes precedence over external repo. Matching is done on SRPM name - if component is included in tag repo (modular) then none of binary RPMs built from the same SRPM name would be included from external repo (platform). So, AFAIK, modular content should already have precedence over platform.

@ppisar: Based on the information from @mizdebsk, can you make an empty commit on perl-bootstrap:5.24 and try the module build again please? I don't have commit access on your repo to try this.

@mizdebsk I don't see that in a code. The mergerepo_c and mergerepos python script in koji prioritize tag repo only when there are SRPMs with the same NVRs, otherwise it takes the one with highest NVR.

But sure, @ppisar, can you test it again now?

I pushed a dummy commit 34a4ed9f, but the MBS reuses already built components instead of rebuilding them. It looks like somebody changed a build strategy. Thus I'm unable to fix the wrongly build components by rebuilding them. See https://mbs.fedoraproject.org/module-build-service/1/module-builds/1504.

Regardless of that some builds fail with 'duplicate key value violates unique constraint "rpminfo_unique_nvra"' now, example https://koji.fedoraproject.org/koji/taskinfo?taskID=24530900.

On the other hand it looks like Koji prefers module RPMs now. Example https://koji.fedoraproject.org/koji/taskinfo?taskID=24531024.

Should I report the two new issues, or I are you going do deal with them in frame of this bug report?

Yes, report them please.

So, this issue (838) can be closed now, right?

You can close this.

I reported the two new issues as #846 and #847.

After enabling MSE, building perl-bootstrap:5.26 expanded to platform:f29 fails with this very same mistake:

MBS build https://mbs.fedoraproject.org/module-build-service/1/module-builds/1614, perl-IO-Compress failed in root.log https://koji.fedoraproject.org/koji/taskinfo?taskID=26188001 because it wants to use bare perl-Compress-Raw-Bzip2-2.080-1.fc29.armv7hl instead of modular perl-Compress-Raw-Bzip2-2.080-1.module_1614+a1a91090. perl-Compress-Raw-Bzip2 is a binary package produced by perl.spec in previous build group.

Also the root.log of modular perl-Compress-Raw-Bzip2-2.080-1.module_1614+a1a91090 https://kojipkgs.fedoraproject.org//work/tasks/8755/26188755/root.log shows the packages were mixed. All Perl packages should come from the same module. None from a bare repository.

My module is affected by a similar issue (ursine packages conflict with modular packages), but my case would be solved by configuring Koji tags with repo_include_all=False, so I opened issue #957