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 1698504 - No seamless upgrade to fc30 because of eclipse
Summary: No seamless upgrade to fc30 because of eclipse
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: eclipse
Version: 30
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Mat Booth
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException
Depends On: 1692089
Blocks: F30FinalFreezeException 1699977
TreeView+ depends on / blocked
 
Reported: 2019-04-10 13:53 UTC by Michael
Modified: 2019-04-25 19:52 UTC (History)
15 users (show)

Fixed In Version: eclipse-4.11-4.fc30
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-25 19:52:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Michael 2019-04-10 13:53:07 UTC
Description of problem:
An installation of Fedora 29 with the package group "Fedora Eclipse" installed cannot be upgraded seamlessly to Fedora 30 (beta). 

Version-Release number of selected component (if applicable):
latest

How reproducible:


Steps to Reproduce:
1. Fedora 29 with package group "Fedora Eclipse" and all updated installed.
2. sudo dnf system-upgrade download --refresh --releasever=30 --setopt='module_platform_id=platform:f30' --enablerepo=updates-testing-modular --enablerepo=updates-testing

Actual results:

Error: 
 Problem 1: package eclipse-recommenders-2.5.4-2.fc29.noarch requires maven-resolver-transport-file, but none of the providers can be installed
  - package eclipse-recommenders-2.5.4-2.fc29.noarch requires osgi(org.apache.maven.resolver.transport.file), but none of the providers can be installed
  - package maven-resolver-transport-file-1:1.3.1-2.fc30.noarch requires mvn(org.apache.maven.resolver:maven-resolver-spi) = 1.3.1, but none of the providers can be installed
  - maven-resolver-transport-file-1:1.1.1-3.fc29.noarch does not belong to a distupgrade repository
  - problem with installed package eclipse-recommenders-2.5.4-2.fc29.noarch
  - package maven-resolver-spi-1:1.3.1-2.fc30.noarch is excluded
 Problem 2: problem with installed package httpcomponents-client-cache-4.5.5-5.fc29.noarch
  - package httpcomponents-client-cache-4.5.6-3.fc30.noarch requires mvn(org.apache.httpcomponents:httpclient) = 4.5.6, but none of the providers can be installed
  - httpcomponents-client-cache-4.5.5-5.fc29.noarch does not belong to a distupgrade repository
  - package httpcomponents-client-4.5.6-3.fc30.noarch is excluded
 Problem 3: problem with installed package maven-resolver-transport-http-1:1.1.1-3.fc29.noarch
  - package maven-resolver-transport-http-1:1.3.1-2.fc30.noarch requires mvn(org.apache.maven.resolver:maven-resolver-util) = 1.3.1, but none of the providers can be installed
  - maven-resolver-transport-http-1:1.1.1-3.fc29.noarch does not belong to a distupgrade repository
  - package maven-resolver-util-1:1.3.1-2.fc30.noarch is excluded
(try to add '--skip-broken' to skip uninstallable packages)


Expected results:
No errors.

Additional info:
A workaround is to use the --allowerasing option.

Comment 1 Mat Booth 2019-04-10 15:25:23 UTC
Hmm, I suppose I missed adding Obsoletes to eclipse for this package that was retired -- thanks for filing a bug.

Comment 2 Fedora Update System 2019-04-11 09:44:43 UTC
eclipse-4.11-4.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-5987976362

Comment 3 Fedora Update System 2019-04-13 01:57:59 UTC
eclipse-4.11-4.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-5987976362

Comment 4 Adam Williamson 2019-04-15 18:23:01 UTC
There actually look to be three different problems reported here, and the update only fixes the first?

The second - involving httpcomponents-client - seems to be also reported as https://bugzilla.redhat.com/show_bug.cgi?id=1699852 , so we can use that bug to track it.

But I think this:

"Problem 3: problem with installed package maven-resolver-transport-http-1:1.1.1-3.fc29.noarch
  - package maven-resolver-transport-http-1:1.3.1-2.fc30.noarch requires mvn(org.apache.maven.resolver:maven-resolver-util) = 1.3.1, but none of the providers can be installed
  - maven-resolver-transport-http-1:1.1.1-3.fc29.noarch does not belong to a distupgrade repository
  - package maven-resolver-util-1:1.3.1-2.fc30.noarch is excluded"

is another separate problem which it doesn't look like the update would fix?

Comment 5 Mat Booth 2019-04-15 19:20:08 UTC
(In reply to Adam Williamson from comment #4)
> There actually look to be three different problems reported here, and the
> update only fixes the first?
> 
> The second - involving httpcomponents-client - seems to be also reported as
> https://bugzilla.redhat.com/show_bug.cgi?id=1699852 , so we can use that bug
> to track it.
> 
> But I think this:
> 
> "Problem 3: problem with installed package
> maven-resolver-transport-http-1:1.1.1-3.fc29.noarch
>   - package maven-resolver-transport-http-1:1.3.1-2.fc30.noarch requires
> mvn(org.apache.maven.resolver:maven-resolver-util) = 1.3.1, but none of the
> providers can be installed
>   - maven-resolver-transport-http-1:1.1.1-3.fc29.noarch does not belong to a
> distupgrade repository
>   - package maven-resolver-util-1:1.3.1-2.fc30.noarch is excluded"
> 
> is another separate problem which it doesn't look like the update would fix?

Yep. My guess would be because the modular branch of maven-resolver is older than the f30 branch: https://src.fedoraproject.org/rpms/maven-resolver/commits/master

And (for reasons that are beyond me) dnf wants to upgrade to the modular version instead of the f30 version.

Comment 6 Geoffrey Marr 2019-04-15 21:08:18 UTC
Discussed during the 2019-04-15 blocker review meeting: [1]

The decision to classify this bug as an "AcceptedFreezeException" was made as this is another typical 'packaging issue affects upgrade' bug, we always like to fix these during freeze so upgrades work.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-04-15/f30-blocker-review.2019-04-15-16.03.txt

Comment 7 Adam Williamson 2019-04-15 21:09:24 UTC
Because it's a default module stream:

https://pagure.io/releng/fedora-module-defaults/blob/master/f/maven.yaml

Comment 8 Mat Booth 2019-04-15 22:08:51 UTC
(In reply to Adam Williamson from comment #7)
> Because it's a default module stream:
> 
> https://pagure.io/releng/fedora-module-defaults/blob/master/f/maven.yaml

If a default module package trumps the higher NVR of the non-module package, then I don't think your solution to bug 1699852 will work either, right?

Isn't the correct solution to bring the module up to date with the F30 version? Please file bugs against the module that is providing maven-resolver and httpcomponents.

Comment 9 Adam Williamson 2019-04-15 22:12:50 UTC
"If a default module package trumps the higher NVR of the non-module package, then I don't think your solution to bug 1699852 will work either, right?"

My solution? I haven't solved anything :) I'm just poking bug reports here...

"Isn't the correct solution to bring the module up to date with the F30 version?"

I don't know. It depends what the maven maintainers / module owners are trying to do, I guess. This module stuff is fairly new to me as well, I don't know all the edges of it yet. To be clear, is the problem here that when you build Eclipse, it builds against the non-modular maven? Or are these manually-specified dependencies and you just picked the versions of the dependencies based on the non-modular maven package versions, not realizing that these are no longer the defaults?

Comment 10 Mat Booth 2019-04-15 22:29:42 UTC
(In reply to Adam Williamson from comment #9)
> To be clear, is the problem here that
> when you build Eclipse, it builds against the non-modular maven?

Yes, necessarily so because FESCO decided not to implement ursa-major. There is no other way than also modularising Eclipse (which is a task I have not yet completed.)

Comment 11 Adam Williamson 2019-04-15 22:31:07 UTC
hmm, in that case, it doesn't seem right that a module can get a default stream without all dependencies of that module being a part of it.

sgallagh, wdyt?

Comment 12 Mat Booth 2019-04-15 22:35:01 UTC
(In reply to Mat Booth from comment #10)
> (In reply to Adam Williamson from comment #9)
> > To be clear, is the problem here that
> > when you build Eclipse, it builds against the non-modular maven?
> 
> Yes, necessarily so because FESCO decided not to implement ursa-major. There
> is no other way than also modularising Eclipse (which is a task I have not
> yet completed.)

FWIW, building against non-modulularised deps is not in-and-of-itself really a problem. The problem from my PoV is that the system upgrade refuses to upgrade packages because the default module contains *older* NVRs than F30 does, even though some other non-modular package has a dep on the newer NVR from non-modular F30 repo.

Comment 13 Mat Booth 2019-04-15 22:42:51 UTC
CC'ing mizdebsk as owner of the maven/ant modules: It seems that system upgrades fail if the non-modular RPM is newer than the modularised RPM (and something requires the newer non-modular version). I guess that the modularised RPM should be updated to at least the same NVR as the F30 branch to avoid this mess, WDYT?

Comment 14 Mikolaj Izdebski 2019-04-16 02:05:49 UTC
I can reproduce the dependency problem involving httpcomponents-client and I will fix it.
I can't reproduce the other issue involving maven-resolver, but I will apply a similar fix.
I will provide more details once I confirm that the fix is working as expected.

Comment 15 Fedora Update System 2019-04-16 21:24:25 UTC
maven-3.5-2820190416211833.819b5873 has been submitted as an update to Fedora 30 Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-dd28e893bc

Comment 16 Mikolaj Izdebski 2019-04-16 21:32:42 UTC
I could not verify my fix as ODCS is broken right now. I've submitted update and I'll verify the fix once the update is pushed to testing.

Comment 17 Mikolaj Izdebski 2019-04-17 11:02:16 UTC
Tested with ODCS compose 250 - the problem seems to be fixed.

The issue in general is that modular packages can conflict with packages from other modules, including platform module.
Keeping the same package version across all modules defeats the purpose of having modules in the first place.
A better generic solution would be to avoid conflicts, by namespacing parts that can cause conflict (file paths, package names, virtual provides etc.)

Comment 18 Mat Booth 2019-04-17 11:51:41 UTC
(In reply to Mikolaj Izdebski from comment #17)
> Tested with ODCS compose 250 - the problem seems to be fixed.
> 
> The issue in general is that modular packages can conflict with packages
> from other modules, including platform module.
> Keeping the same package version across all modules defeats the purpose of
> having modules in the first place.
> A better generic solution would be to avoid conflicts, by namespacing parts
> that can cause conflict (file paths, package names, virtual provides etc.)

In practice it'll only be a problem in F30 because these packages are retired in F31, right?

Comment 19 Mikolaj Izdebski 2019-04-17 13:09:02 UTC
(In reply to Mat Booth from comment #18)
> In practice it'll only be a problem in F30 because these packages are
> retired in F31, right?

No, because these packages won't be retired. In future Fedora releases the problem will become even bigger as modular packages will start diverging from non-modular ones. I am already working on "module namespacing" feature that will make Java modules (maven, ant) parallel-installable with "base" Fedora packages, which should solve the problem. There is no ETA for that as my resources are quite limited.

Comment 20 Fedora Update System 2019-04-17 13:41:44 UTC
maven-3.5-2820190416211833.819b5873 has been pushed to the Fedora 30 Modular testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-dd28e893bc

Comment 21 Fedora Update System 2019-04-17 16:04:36 UTC
eclipse-4.11-4.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

Comment 22 Stephen Gallagher 2019-04-22 12:36:24 UTC
(In reply to Adam Williamson from comment #11)
> hmm, in that case, it doesn't seem right that a module can get a default
> stream without all dependencies of that module being a part of it.
> 
> sgallagh, wdyt?

No, I think the issue is that default streams are intended to be standard upgrade paths. Downgrading when updating to F30 is an upgradepath bug, regardless of whether it's a standard RPM or an RPM from a default stream.

Comment 23 Mikolaj Izdebski 2019-04-25 19:09:51 UTC
Reopening as the issue is not fully fixed until maven module update goes to stable.

Comment 24 Fedora Update System 2019-04-25 19:33:18 UTC
maven-3.5-2820190416211833.819b5873 has been pushed to the Fedora 30 Modular stable repository. If problems still persist, 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.