Hide Forgot
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.
Hmm, I suppose I missed adding Obsoletes to eclipse for this package that was retired -- thanks for filing a bug.
eclipse-4.11-4.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-5987976362
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
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?
(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.
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
Because it's a default module stream: https://pagure.io/releng/fedora-module-defaults/blob/master/f/maven.yaml
(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.
"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?
(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.)
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?
(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.
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?
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.
maven-3.5-2820190416211833.819b5873 has been submitted as an update to Fedora 30 Modular. https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-dd28e893bc
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.
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 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?
(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.
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
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.
(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.
Reopening as the issue is not fully fixed until maven module update goes to stable.
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.