@mbooth, you are correct. MBS will generate conflicts in the module-build-macros spec file to prevent filtered RPMs from Buildrequires (and their requires) from being available in the buildroot. It's a bit hacky, but the behavior is intended.

I believe the reason this is done is because MBS adds modules to the buildroot using tag inheritance, but if those RPMs are filtered, they should not have been made available in the buildroot since those RPMs would not be installed during normal circumstances. This is a work-around for this.

I don't have any particular advice for you on how to address your issue. @psabata, could you please provide some guidance here?

You cannot buildrequire RPM from another module if that RPM is filtered out from that module. If RPM is filtered out, it simply means that the RPM is not part of a module after the module is built.

We had to choose the implementation using Conflicts, because Koji cannot filter out particular RPMs from buildroot. It can only filter out particular Koji builds.

I think you have just three possible ways to fix that:
a) Persuade maintainer of module which filters the RPM to stop filtering it.
b) Find different module which provides that RPM and does not filter it.
c) Build that RPM yourself in your module.

@asamalik, maybe this could be documented in some sort of FAQ in modular docs. This error might be confusing to users. What do you think?

@mbooth, in this case, MBS team cannot help you any further I'm afraid. MBS acts as expected here.

You cannot buildrequire RPM from another module if that RPM is filtered out from that module. If RPM is filtered out, it simply means that the RPM is not part of a module after the module is built.

@jkaluza Wait, I'm not BR'ing an RPM from a module that is filtering it. It is filtered out of the runtime requirement maven module, but it is not filtered out of the buildtime requirement of javapackages-tools module.

Here, you can see my BR is on javapackages-tools module, and not maven:

https://src.fedoraproject.org/modules/eclipse/blob/92fbbf6251c35c5b5a6b58c209cb707f36e56558/f/eclipse.yaml#_13

My collection builds fine if I avoid specifying the runtime requirement on maven but that is obviously harmful to users.

Hi @mizdebsk do you have an opinion on this? Am I doing the right thing with this dependency section?

@asamalik, maybe this could be documented in some sort of FAQ in modular docs. This error might be confusing to users. What do you think?

Yes, together with a few other people I'm working on a better structure of our docs that will also cover this. I'm making a note specifically about this.

@mbooth, you are correct. MBS will generate conflicts in the module-build-macros spec file to prevent filtered RPMs from Buildrequires (and their requires) from being available in the buildroot. It's a bit hacky, but the behavior is intended.

Then the intended behaviour is not the actual behaviour. These conflicts appear to come from my module's runtime requirements.

As I mention above, my collection builds fine if I avoid specifying the runtime requirement on maven but that is obviously harmful to users.

@jkaluza @mprahl Oh I just had a thought!

Because of https://pagure.io/fm-orchestrator/issue/1267 my module has to BR itself. So you are right that in a technical sense, the maven module is a R of a BR after all:

• eclipse Rs maven
• eclipse BRs eclipse

Can we make an exception here? When conflicts are generated, we should not consider Rs of a BR on itself. WDYT?

@mbooth, that makes sense to me. I'm going to bring this up with @psabata on Friday to get his thoughts.

@mbooth, that makes sense to me. I'm going to bring this up with @psabata on Friday to get his thoughts.

@mprahl Although I still think special-casing self-BRs would workaround my specific problem, on IRC @mizdebsk suggested this is actually a concrete instance of bug #1321 in case that changes things:

[12:17:01] <mizdebsk> aha, i see what is wrong
[12:18:11] <mizdebsk> compare outputs of the following 2 commands:
[12:18:19] <mizdebsk> dnf -q --repofrompath module-eclipse-2019-06-3020190902131726-dc2e1958-build-1255166-armhfp,https://kojipkgs.fedoraproject.org/repos/module-eclipse-2019-06-3020190902131726-dc2e1958-build/1255166/armhfp --repo module-eclipse-2019-06-3020190902131726-dc2e1958-build-1255166-armhfp repoquery plexus-containers-container-default
[12:18:24] <mizdebsk> curl -s https://kojipkgs.fedoraproject.org/repos/module-eclipse-2019-06-3020190902131726-dc2e1958-build/1255166/armhfp/pkglist | grep plexus-containers-container-default
[12:19:11] <mizdebsk> the first one shows that only one plexus-containers-container-default pm is available in repodata while the second shows that both rpms should be
[12:19:41] <jkaluza> mizdebsk: is that dnf bug?
[12:19:50] <mizdebsk> so this is another instance of https://pagure.io/fm-orchestrator/issue/1321
[12:20:15] <mizdebsk> koji creates repo with both rpms, but then mergerepo breaks them

@mbooth, that makes sense to me. I'm going to bring this up with @psabata on Friday to get his thoughts.

Any news here @mprahl ?

@mbooth, based on your previous comment saying that it was actually an instance of bug #1321, we decided to shift our focus to that. If that has changed, please let me know.

We hav closed #1321 and this bug should be duplicate of that bug. I'm closing also this one.

Reopening, I still see this problem. The fix for #1321 has had no effect for my use-case. See a recent build: https://koji.fedoraproject.org/koji/taskinfo?taskID=39379750

DEBUG util.py:596:  Error: 
DEBUG util.py:596:   Problem: problem with installed package module-build-macros-0.1-1.module_f30+7132+2576adb8.noarch
DEBUG util.py:596:    - package module-build-macros-0.1-1.module_f30+7132+2576adb8.noarch conflicts with plexus-containers-container-default = 1.7.1-8.module_f28+3939+dc18cd75 provided by plexus-containers-container-default-1.7.1-8.module_f28+3939+dc18cd75.noarch
DEBUG util.py:596:    - package maven-project-2.2.1-59.module_f28+3695+340f1066.noarch requires mvn(org.codehaus.plexus:plexus-container-default), but none of the providers can be installed
DEBUG util.py:596:    - package maven-antrun-plugin-1.8-6.module_f28+3695+340f1066.noarch requires mvn(org.apache.maven:maven-project), but none of the providers can be installed
DEBUG util.py:596:    - package apache-commons-parent-43-2.module_f28+3695+340f1066.noarch requires mvn(org.apache.maven.plugins:maven-antrun-plugin), but none of the providers can be installed
DEBUG util.py:596:    - conflicting requests

It might be worth restating because this bug was dormant for a while: Because Eclipse has a self-dependency for bootstrapping -- this bug prevents me from doing normal rebuilds without a full rebootstrapping cycle.

From my PoV one of the solutions are needed:

• Allow specifying exactly the revision of a module against which to build in the BR section of the modulemd -- so I can always build against the last bootstrap build instead of the last full build that contains the erroneous conflicts.
• When conflicts are generated for module-build-macros, we should not consider the Rs of a BR on itself -- so I can build against the last full build because it won't contain the erroneous conflicts

If that has changed, please let me know.

@mprahl, consider this me letting you know ;-)