Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1800528 - Modules make eclipse non-installable
Summary: Modules make eclipse non-installable
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora Modules
Classification: Fedora
Component: maven
Version: unspecified
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ---
Assignee: Stephen Gallagher
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-02-07 11:12 UTC by Miro Hrončok
Modified: 2021-03-12 09:54 UTC (History)
20 users (show)

Fixed In Version: maven-3.5-3020200407193626.a91457f8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-18 01:29:36 UTC
Type: Bug
Embargoed:
bcotton: fedora_prioritized_bug+


Attachments (Terms of Use)

Description Miro Hrončok 2020-02-07 11:12:08 UTC
Description of problem:
Due to the content in default modules and/or the way our modules work, we cannot install nonmodular eclipse. The packages in eclipse stack are all fine and installable with modular repositories disabled.

Opening at dnf, so the dnf team can properly triage this.


Version-Release number of selected component (if applicable):
dnf-4.2.18-1.fc31
eclipse-platform-1:4.14-5.fc31
glassfish-el-3.0.1-0.11.b08.fc31
glassfish-el-3.0.1-0.12.b08.module_f31+6519+12cd0b27
glassfish-el-3.0.1-0.12.b08.module_f31+6793+1c93c38e


How reproducible:
Always.


Steps to Reproduce:
1. $ dnf --enablerepo=updates-testing{,-modular} install eclipse
2. $ dnf --enablerepo=updates-testing --disablerepo=\*-modular install eclipse


Actual results:
The first command fails, the second succeeds.

Error: 
 Problem: conflicting requests
  - package eclipse-jdt-1:4.14-5.fc31.noarch requires eclipse-platform = 1:4.14-5.fc31, but none of the providers can be installed
  - package eclipse-jdt-1:4.11-3.fc31.noarch requires eclipse-platform = 1:4.11-3.fc31, but none of the providers can be installed
  - package eclipse-platform-1:4.14-5.fc31.x86_64 requires glassfish-el >= 3.0.1, but none of the providers can be installed
  - package eclipse-platform-1:4.11-3.fc31.x86_64 requires glassfish-el >= 3.0.1, but none of the providers can be installed
  - package glassfish-el-3.0.1-0.12.b08.module_f31+6519+12cd0b27.noarch is filtered out by modular filtering
  - package glassfish-el-3.0.1-0.12.b08.module_f31+6793+1c93c38e.noarch is filtered out by modular filtering
  - package glassfish-el-3.0.1-0.11.b08.fc31.noarch is filtered out by modular filtering


Expected results:
The first command should have the same result as the second: Installed eclipse.

Comment 2 Jaroslav Mracek 2020-02-17 13:41:10 UTC
I investigated the issue and I found that glassfish-el package was filtered out by maven:3.5:2820190416211833:819b5873:x86_64 module. Maven modules provides glassfish-el.src and glassfish-el-api.noarch and because maven:3.5 is a default module glassfish-el is filtered out.

Comment 3 Jaroslav Mracek 2020-02-17 14:14:01 UTC
The problem could be resolved by update of maven:3.5. They should use glassfish-el from base repo or pack glassfish-el as a compact package.

Comment 4 Miro Hrončok 2020-02-17 18:33:37 UTC
The problem could also be resolved by not having default modular streams.

Comment 5 Miro Hrončok 2020-02-17 18:34:48 UTC
Also note that the bug is now assigned to Orphan Owner :(

Comment 6 Jaroslav Mracek 2020-02-19 09:36:24 UTC
(In reply to Miro Hrončok from comment #4)
> The problem could also be resolved by not having default modular streams.

I would like to open a discussion what is allowed in modules. I believe that module cannot break other components. Modules are not containers but an alternative content. It means that after switching into module (doesn't matter if it is default or not), it must not create additional broken dependencies. Modules must be considered as additional repositories shipped with Fedora. Modules with a default stream are like Fedora repository and without defaults like fedora-cisco-openh264. Genera expectation from fedora-cisco-openh264 is that after repo is enable everything works like before plus there will be an additional content.

I would like to highlight that not using defaults is not a solution of the problem. It only makes problem less visible.

Comment 7 Mikolaj Izdebski 2020-02-19 09:45:12 UTC
None of the affected packages are are part of maven module. They are either ursine or come from eclipse module (module builds #6793 and #6519 are eclipse:latest builds). Moving the bug to eclipse.

Comment 8 Mikolaj Izdebski 2020-02-19 09:55:23 UTC
Further note: maven:3.5 available from Fedora 31 updates no longer filters out glassfish-el. maven:3.5 in base Fedora 31 (GA) does indeed filter glassfish-el, but that module can't be altered post GA.

Comment 9 Jaroslav Mracek 2020-02-19 12:44:51 UTC
Let me summarize the issue. Module maven:3.5 in fedora-modular repository makes eclipse uninstalable (tested on Fedora 31).

See output:
sudo dnf install --repo=fedora,fedora-modular eclipse
Last metadata expiration check: 0:01:07 ago on Wed 19 Feb 2020 01:20:58 PM CET.
Error: 
 Problem: package eclipse-jdt-1:4.11-3.fc31.noarch requires eclipse-platform = 1:4.11-3.fc31, but none of the providers can be installed
  - package eclipse-platform-1:4.11-3.fc31.x86_64 requires glassfish-el >= 3.0.1, but none of the providers can be installed
  - conflicting requests
  - package glassfish-el-3.0.1-0.12.b08.module_f31+6519+12cd0b27.noarch is excluded
  - package glassfish-el-3.0.1-0.11.b08.fc31.noarch is excluded
(try to add '--skip-broken' to skip uninstallable packages)


The issue was resolved by dropping glassfish-el but not when fedora-modular is available.
See: 
sudo dnf install --repo=fedora,updates-modular eclipse
sudo dnf install --repo=fedora,updates-modular,fedora-modular eclipse

The issue is same like with incorrect obsoletes in rpm in Fedora repo. You cannot resolve the issue by dropping that problematic obsoletes in next release and when someone point that it doesn't work just to move the issue to package that was obsoleted.

Now we have to try once again from beginning. The issue is there and it is caused by maven:3.5. Prove it is quite easy. 
sudo dnf install eclipse  # transaction fail
sudo dnf module disable maven:3.5
sudo dnf install eclipse  # no issue

How to resolve the issue?
In maven:module provide all missing requirements to eclipse or find a better way. I strongly to recommend to fix not only 3.5 stream.
Convince eclipse people to not require glassfish-el or glassfish-el-api. It must be done by very nice way, because as I said it is not their problem.

Comment 10 Mikolaj Izdebski 2020-02-19 13:03:28 UTC
I'd argue that the issue is not in maven module. But even assuming it is, there is nothing that can be fixed in maven module - module versions in GA repository cannot be altered.

(In reply to Jaroslav Mracek from comment #9)
> How to resolve the issue?
> In maven:module provide all missing requirements to eclipse or find a better
> way.

Providing dependencies for Eclipse is beyond scope of maven module. The purpose of maven module is to provide Maven. I'm not going to add packages unrelated to Maven to maven module.

Comment 11 Jaroslav Mracek 2020-02-19 13:22:34 UTC
(In reply to Mikolaj Izdebski from comment #10)
> I'd argue that the issue is not in maven module. But even assuming it is,
> there is nothing that can be fixed in maven module - module versions in GA
> repository cannot be altered.
> 
> (In reply to Jaroslav Mracek from comment #9)
> > How to resolve the issue?
> > In maven:module provide all missing requirements to eclipse or find a better
> > way.
> 
> Providing dependencies for Eclipse is beyond scope of maven module. The
> purpose of maven module is to provide Maven. I'm not going to add packages
> unrelated to Maven to maven module.

A can also argue that maven in GA provided glassfish-el-api and glassfish-el.src but not glassfish-el.noarch. In case that you will provide also glassfish-el.noarch it would resolve the issue. I would recommend to cooperate with maintainers of glassfish-el to synchronize steps. Please also inform maintainers of eclipse about the progress.

I am sorry that I tried to suggest a solution for the issue and it is completely up to you how you will resolve it. I hope that you will provide an alternative solution in reasonable time.

Comment 12 Alex Scheel 2020-02-19 13:33:24 UTC
> Providing dependencies for Eclipse is beyond scope of maven module. The purpose of maven module is to provide Maven. I'm not going to add packages unrelated to Maven to maven module.

Per https://pagure.io/modularity/issue/146, all packages must be exposed via the API of a default module stream; none can be filtered.

glassfish-el is part of the maven module's default stream, and thus cannot be filtered out. The same holds for all the other packages in the filtered: section of the maven module's default streams.

Comment 13 Ben Cotton 2020-03-18 19:11:32 UTC
Reassigning to sgallagh to step in with a fix as a provenpackager as agreed in last week's PrioritizedBugs meeting:
https://meetbot.fedoraproject.org/teams/fedora_prioritized_bugs_and_issues/fedora_prioritized_bugs_and_issues.2020-03-11-15.00.log.html#l-156

Comment 14 Stephen Gallagher 2020-04-07 14:41:25 UTC
This fell off my radar. Can someone remind me what we agreed on here?

Comment 15 Miro Hrončok 2020-04-07 14:44:17 UTC
(In reply to Alex Scheel from comment #12)
> > Providing dependencies for Eclipse is beyond scope of maven module. The purpose of maven module is to provide Maven. I'm not going to add packages unrelated to Maven to maven module.
> 
> Per https://pagure.io/modularity/issue/146, all packages must be exposed via
> the API of a default module stream; none can be filtered.
> 
> glassfish-el is part of the maven module's default stream, and thus cannot
> be filtered out. The same holds for all the other packages in the filtered:
> section of the maven module's default streams.

This, basically. Do not filter out glassfish-el.

Comment 16 Fedora Update System 2020-04-08 00:45:21 UTC
FEDORA-MODULAR-2020-885927b4dc has been submitted as an update to Fedora 30 Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-885927b4dc

Comment 17 Stephen Gallagher 2020-04-08 01:02:53 UTC
Because of how this module is built, there is only one update marked as "Fedora 30 Modular". This will go to stable for both F30 and F31 at the same time, so if you want to provide karma, please do so on https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-885927b4dc

Comment 18 Fedora Update System 2020-04-09 20:51:15 UTC
FEDORA-MODULAR-2020-885927b4dc has been pushed to the Fedora 30 Modular testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2020-885927b4dc

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 19 Miro Hrončok 2020-04-09 22:09:51 UTC
[root@7a52f0f7a161 /]# dnf --enablerepo=updates-testing{,-modular} install eclipse
Fedora Modular 31 - x86_64 - Test Updates                171 kB/s | 1.1 MB     00:06    
Fedora 31 - x86_64 - Test Updates                        794 kB/s | 7.1 MB     00:09    
Last metadata expiration check: 0:00:06 ago on Thu Apr  9 22:07:44 2020.
Error: 
 Problem: conflicting requests
  - package eclipse-jdt-1:4.14-5.fc31.noarch requires eclipse-platform = 1:4.14-5.fc31, but none of the providers can be installed
  - package eclipse-jdt-1:4.11-3.fc31.noarch requires eclipse-platform = 1:4.11-3.fc31, but none of the providers can be installed
  - package eclipse-platform-1:4.14-5.fc31.x86_64 requires glassfish-el >= 3.0.1, but none of the providers can be installed
  - package eclipse-platform-1:4.11-3.fc31.x86_64 requires glassfish-el >= 3.0.1, but none of the providers can be installed
  - package glassfish-el-3.0.1-0.12.b08.module_f31+6519+12cd0b27.noarch is filtered out by modular filtering
  - package glassfish-el-3.0.1-0.12.b08.module_f31+6793+1c93c38e.noarch is filtered out by modular filtering
  - package glassfish-el-3.0.1-0.13.b08.module_f31+8483+4971e288.noarch is filtered out by modular filtering
  - package glassfish-el-3.0.1-0.11.b08.fc31.noarch is filtered out by modular filtering
(try to add '--skip-broken' to skip uninstallable packages)



I know no way of saying whether the update has hit the mirrors yet, so I'll retest in couple days.

Comment 20 Miro Hrončok 2020-04-12 09:19:27 UTC
Works now, will add karma.

Comment 21 Fedora Update System 2020-04-18 01:29:36 UTC
FEDORA-MODULAR-2020-885927b4dc has been pushed to the Fedora 30 Modular stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.