Bug 2091862
| Summary: | can't install slf4j-jdk14 slf4j due to conflicts between modules | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Sandro Bonazzola <sbonazzo> |
| Component: | maven-3.6-module | Assignee: | Mikolaj Izdebski <mizdebsk> |
| Status: | NEW --- | QA Contact: | RHEL CS Apps Subsystem QE <rhel-cs-apps-subsystem-qe> |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | CentOS Stream | CC: | amepatil, bstinson, hhorak, hostedvideorn, jfont, jrichards2, jwboyer, mkoncek, mperina, wpinheir |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Sandro Bonazzola
2022-05-31 08:08:00 UTC
Forgot to mention that after dnf install slf4j-jdk14 you'll get: dnf update Last metadata expiration check: 0:13:35 ago on Tue May 31 08:03:18 2022. Error: Problem: package slf4j-jdk14-1.7.25-4.module_el8.5.0+922+9f7ad99e.noarch requires mvn(org.slf4j:slf4j-api) = 1.7.25, but none of the providers can be installed - cannot install both slf4j-1.7.28-3.module_el8.4.0+652+27abba4b.noarch and slf4j-1.7.25-4.module_el8.5.0+922+9f7ad99e.noarch - cannot install both slf4j-1.7.28-3.module_el8.4.0+652+27abba4b.noarch and slf4j-1.7.25-4.module_el8.4.0+595+e59c9af2.noarch - cannot install both slf4j-1.7.25-4.module_el8.0.0+30+832da3a1.noarch and slf4j-1.7.28-3.module_el8.4.0+652+27abba4b.noarch - cannot install both slf4j-1.7.25-4.module_el8.5.0+922+9f7ad99e.noarch and slf4j-1.7.28-3.module_el8.4.0+652+27abba4b.noarch - cannot install the best update candidate for package slf4j-jdk14-1.7.25-4.module_el8.5.0+922+9f7ad99e.noarch - cannot install the best update candidate for package slf4j-1.7.25-4.module_el8.5.0+922+9f7ad99e.noarch - package slf4j-1.7.25-4.module_el8.0.0+39+6a9b6e22.noarch is filtered out by modular filtering - package slf4j-1.7.25-4.module_el8.6.0+1030+8d97e896.noarch is filtered out by modular filtering (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) Confirmed. Tested both on C8S and RHEL 8.7 (without enabling powertools) There are package conflicts between slf4j from module maven:3.6 (version 1.7.28) and pki-deps and javapackages-tools (version 1.7.25). I am not sure if there is anything to be fixed, these modules are intended for different purposes: * javapackages-tools is used to build rpms of java packages * maven is used to build upstream java projects * pki-deps is used in production environments Sandro, what is your use case? Could you work with only slf4j version 1.7.25 without updating it? (In reply to Marián Konček from comment #4) > I am not sure if there is anything to be fixed, these modules are intended > for different purposes: > * javapackages-tools is used to build rpms of java packages > * maven is used to build upstream java projects > * pki-deps is used in production environments > > Sandro, what is your use case? Could you work with only slf4j version 1.7.25 > without updating it? We are using javapackages-tools to package upstream projects under oVirt organization that are built using maven and require libraries which are packaged only under pki-deps module. So we need all of those modules in order to build. @mperina can probably elaborate more on the dependency tree and requirements. I think maven and javapackages-tools should have the same slf4j version and they are not aligned by mistake. I believe you can disable the maven module and you will be able to package java software into rpms just fine. The javapackages-tools module provides all the necessary dependencies (including the maven package). Let me point out the important difference between the javapackages-tools and maven module: 1) Maven is used when you, as a developer, want to build upstream java projects and have maven fetch all the exact dependencies as specified in pom files. 2) Javapackages-tools provides "maven-local", "xmvn" and build macros which are used for building most of the java software in Fedora and RHEL. During such builds, xmvn is used, which acts similar to maven, but fetches only dependencies / plugins installed on the system where the build is executed. If your only intent is to package java software into rpms and you don't have any other unique requirements, you only need "javapackages-tools". So as a developer you can't build upstream (with maven:3.6) and rpms (with javapackages-tools) on the same machine ? Not necessarily, but with modular inter-conflicts it get more complicated. You can do both just fine on Fedora without modules. javapackages-tools module in RHEL is buildroot-only and our aim is to have it working for the purposes of building packages in separate environments. We do not guarantee that it won't conflict with the maven module. When it comes to pki-deps, I examined their module yamls. Both 10.6 and 10.7 use slf4j from the stream maven:3.5. I see two possible solutions: 1) Do not use maven module or use maven:3.5 instead of maven:3.6, this should use slf4j 1.7.25. 2) * Get the stream javapackages-tools:201902 into powertools, this depends on slf4j 1.7.28. I don't know why this newer stream is not present in Centos Stream. * Someone would talk the maintainers of pki-deps to have them change their dependency on slf4j to refer to maven:3.6 and have them rebuild the module. My customer in case 03346123 also has this issue. Starting in Satellite version 6.11, both slf4j and slf4j-jdk14 are dependencies of the satellite, candlepin, katello and jss packages. The difficulty for my customer is that their vulnerability scanner has flagged version 1.7.25-4 of package slf4j as needing to be updated, but dnf doesn't want to install a newer version of package slf4j alongside an older version of package slf4j-jdk14 (version 1.7.25-4 is as high as Red Hat package slf4j-jdk14 goes). any more updates?! when can we expect this to be resolved?! (In reply to Sandro Bonazzola from comment #5) > (In reply to Marián Konček from comment #4) > > I am not sure if there is anything to be fixed, these modules are intended > > for different purposes: > > * javapackages-tools is used to build rpms of java packages > > * maven is used to build upstream java projects > > * pki-deps is used in production environments > > > > Sandro, what is your use case? Could you work with only slf4j version 1.7.25 > > without updating it? > > We are using javapackages-tools to package upstream projects under oVirt > organization that are built using maven and require libraries which are > packaged only under pki-deps module. > So we need all of those modules in order to build. > > @mperina can probably elaborate more on the dependency tree and > requirements. > > I think maven and javapackages-tools should have the same slf4j version and > they are not aligned by mistake. The problem is that we are building java packages on CBS with CRB/PowerTools enabled, because of some other dependencies. With above maven 3.6 is always used instead of 3.5, so the only workaround for our java builds to work is this ugly spec file hack: # Block packages from maven:3.8 to pass the build BuildRequires: maven < 1:3.8.0 BuildRequires: maven-lib < 1:3.8.0 BuildRequires: maven-resolver < 1:1.7.0 BuildRequires: maven-shared-utils < 3.3.4-3 BuildRequires: maven-wagon < 3.5.0 BuildRequires: plexus-cipher < 1.8 BuildRequires: plexus-classworlds < 2.6.0-11 BuildRequires: plexus-containers-component-annotations < 2.1.1 BuildRequires: plexus-interpolation < 1.26-11 BuildRequires: plexus-sec-dispatcher < 1.5 BuildRequires: plexus-utils < 3.3.0-10 BuildRequires: sisu < 1:0.3.5 (In reply to Martin Perina from comment #16) > (In reply to Sandro Bonazzola from comment #5) > > (In reply to Marián Konček from comment #4) > > > I am not sure if there is anything to be fixed, these modules are intended > > > for different purposes: > > > * javapackages-tools is used to build rpms of java packages > > > * maven is used to build upstream java projects > > > * pki-deps is used in production environments > > > > > > Sandro, what is your use case? Could you work with only slf4j version 1.7.25 > > > without updating it? > > > > We are using javapackages-tools to package upstream projects under oVirt > > organization that are built using maven and require libraries which are > > packaged only under pki-deps module. > > So we need all of those modules in order to build. > > > > @mperina can probably elaborate more on the dependency tree and > > requirements. > > > > I think maven and javapackages-tools should have the same slf4j version and > > they are not aligned by mistake. > > The problem is that we are building java packages on CBS with CRB/PowerTools > enabled, because of some other dependencies. With above maven 3.6 is always > used instead of 3.5, so the only workaround for our java builds to work is > this ugly spec file hack: > > # Block packages from maven:3.8 to pass the build > > BuildRequires: maven < 1:3.8.0 > BuildRequires: maven-lib < 1:3.8.0 > BuildRequires: maven-resolver < 1:1.7.0 > BuildRequires: maven-shared-utils < 3.3.4-3 > BuildRequires: maven-wagon < 3.5.0 > BuildRequires: plexus-cipher < 1.8 > BuildRequires: plexus-classworlds < 2.6.0-11 > BuildRequires: plexus-containers-component-annotations < 2.1.1 > BuildRequires: plexus-interpolation < 1.26-11 > BuildRequires: plexus-sec-dispatcher < 1.5 > BuildRequires: plexus-utils < 3.3.0-10 > BuildRequires: sisu < 1:0.3.5 Ah sorry, that's the current sitation, which is even worse than slf4j version differences between AppStream and CRB/PowerTools. Anyway we were able to workaround the issue with slf4j by spec file buildrequires optimizations (In reply to Martin Perina from comment #17) > Anyway we were able to workaround the issue with slf4j by spec file > buildrequires optimizations Does it mean we can close this BZ? As RHV is in maintenance mode and community around oVirt is not very active, most probably we will not need to build many packages anymore. The workaround is mentioned in Comment 17, so if you think that pasting 12 lines (to prevent using maven 3.8) into spec file of every Java related package that need to be built on CBS for CentOS Stream 8 is a good workaround, the sure feel free to close it. |