Bug 1800528 - Modules make eclipse non-installable
Summary: Modules make eclipse non-installable
Keywords:
Status: ASSIGNED
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: 2020-03-18 19:11 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
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


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