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: | CLOSED MIGRATED | 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: | MigratedToJIRA, Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| 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: | 2023-09-20 14:32:59 UTC | 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. Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug. This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there. Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information. To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like: "Bugzilla Bug" = 1234567 In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information. |