#1400 module-build-macros contains conflicts that prevent building
Opened 4 months ago by mbooth. Modified 2 months ago

Maybe there's something obvious that I'm not understanding, but this seems wrong to me.

The module-build-macros package of my module has conflicts:

https://koji.fedoraproject.org/koji/taskinfo?taskID=37426323

[mbooth@thinkpad-p50 eclipse]$ rpm -qp --conflicts module-build-macros-0.1-1.module_f30+6162+11a08507.noarch.rpm                                                                                       
ant-javadoc = 0:1.10.5-3.module_f28+4207+d722d224     
ant-manual = 0:1.10.5-3.module_f28+4207+d722d224                                                   
antlr-C++ = 0:2.7.7-56.module_f28+3872+5b76729e                                                    
antlr-javadoc = 0:2.7.7-56.module_f28+3872+5b76729e                     
antlr-manual = 0:2.7.7-56.module_f28+3872+5b76729e               
.... etc
plexus-containers = 0:1.7.1-8.module_f28+3939+dc18cd75
plexus-containers-component-javadoc = 0:1.7.1-8.module_f28+3939+dc18cd75                           
plexus-containers-component-metadata = 0:1.7.1-8.module_f28+3939+dc18cd75                          
plexus-containers-container-default = 0:1.7.1-8.module_f28+3939+dc18cd75
plexus-containers-javadoc = 0:1.7.1-8.module_f28+3939+dc18cd75   
.... etc

And this prevents the module components from building:

https://koji.fedoraproject.org/koji/taskinfo?taskID=37427492

DEBUG util.py:585:  BUILDSTDERR: Error: 
DEBUG util.py:585:  BUILDSTDERR:  Problem: problem with installed package module-build-macros-0.1-1.module_f30+6162+11a08507.noarch
DEBUG util.py:585:  BUILDSTDERR:   - package module-build-macros-0.1-1.module_f30+6162+11a08507.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:585:  BUILDSTDERR:   - 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:585:  BUILDSTDERR:   - 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:585:  BUILDSTDERR:   - conflicting requests

Why would MBS be generating conflicts here? It kinda looks like they come from the "filter" list of the runtime requirements (ant and maven modules) but these packages are also present in the buildtime requirements (javapackages-tools and tycho modules) so IMHO these conflicts are clearly wrong.

How can I prevent such conflicts?


@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.

Metadata Update from @jkaluza:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

3 months ago

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 ;-)

Metadata Update from @mbooth:
- Issue status updated to: Open (was: Closed)

2 months ago

Login to comment on this ticket.

Metadata