Description of problem: The javamail update in Fedora 29 is uninstallable due to broken dependencies: $ LANG=en_US.UTF-8 dnf --refresh update Adobe Systems Incorporated 2.7 kB/s | 2.9 kB 00:01 EGI-trustanchors 2.1 kB/s | 2.5 kB 00:01 Fedora Modular 29 - x86_64 46 kB/s | 28 kB 00:00 Fedora Modular 29 - x86_64 - Updates 39 kB/s | 26 kB 00:00 Fedora 29 - x86_64 - Updates 30 kB/s | 28 kB 00:00 Fedora 29 - x86_64 112 kB/s | 28 kB 00:00 RPM Fusion for Fedora 29 - Free - Updates 7.9 kB/s | 9.1 kB 00:01 RPM Fusion for Fedora 29 - Free 18 kB/s | 10 kB 00:00 skype (stable) 2.7 kB/s | 2.9 kB 00:01 Dependencies resolved. Problem: cannot install both javamail-1.6.3-2.module_2663+c0acbe74.noarch and javamail-1.5.2-8.fc29.noarch - package axiom-1.2.14-3.fc29.noarch requires mvn(javax.mail:mail), but none of the providers can be installed - cannot install the best update candidate for package javamail-1.5.2-8.fc29.noarch - cannot install the best update candidate for package axiom-1.2.14-3.fc29.noarch - package javamail-1.5.2-7.module_2512+68251d4e.noarch is excluded - package javamail-1.5.2-8.fc29.noarch is excluded ================================================================================ Package Arch Version Repository Size ================================================================================ Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): javamail noarch 1.6.3-2.module_2663+c0acbe74 updates-modular 683 k Transaction Summary ================================================================================ Skip 1 Package Nothing to do. Complete! Version-Release number of selected component (if applicable): javamail-1.6.3-2.module_2663+c0acbe74.noarch How reproducible: Always Steps to Reproduce: 1. Try to update javamail in Fedora 29 while having a package requiring mvn(javax.mail:mail) is installed 2. The update fails because the new javamail version no longer provides mvn(javax.mail:mail) Actual results: Update fails Expected results: Update successful Additional info: Several packages in Fedora 29 requires mvn(javax.mail:mail): $ LANG=en_US.UTF-8 dnf repoquery --whatrequires 'mvn(javax.mail:mail)' Last metadata expiration check: 0:04:22 ago on Tue 22 Jan 2019 09:21:40 AM CET. axiom-0:1.2.14-3.fc29.noarch axis2-0:1.7.7-2.fc29.noarch jenkins-core-0:1.651.3-8.fc29.noarch jets3t-0:0.9.3-9.fc29.noarch restlet-jse-0:2.3.1-8.fc29.noarch subethasmtp-0:3.1.7-13.fc29.noarch
Is the jmc module enabled on your system? I can reproduce this when the module jmc is enabled but if module jmc is disabled via $ sudo dnf module disable jmc I am able to install axiom without conflicts. I would suggest that as a workaround for the time being. The javamail package in the jmc module seems to attempt (poorly) to supply the old Provides and I will take a look at that. However, 1.6.3 is hiding a major breaking change from 1.5.x as javamail moved under the Eclipse foundation and the coordinates were changed to jakarta.mail rather than javax.mail. I will have to verify if dependants work even if it Provides 'mvn(javax.mail:mail)'.
I cannot reproduce this: $ rpm -q axiom javamail axiom-1.2.14-3.fc29.noarch javamail-1.5.2-8.fc29.noarch $ sudo dnf update <works fine> (In reply to Mattias Ellert from comment #0) > Dependencies resolved. > > Problem: cannot install both javamail-1.6.3-2.module_2663+c0acbe74.noarch > and javamail-1.5.2-8.fc29.noarch This suggests you have the jmc module installed. Fedora modules don't solve the parallel install problem which is what you seem to be seeing. My recommendation would be to either remove axiom or the jmc module. As to how you've managed to get into this state with both of them installed, I've no idea ;-) Maybe I'm missing something...
The module version of jmc is declared "default", i.e. unless you actively disable the module version this is the version you get. I have not chosen the activate this module, it is what you get by default. I understand that if you choose to activate some module some things might break. This is the reason for having modules in the first place. But no module declared "default" should be allowed to break anything. A module declared "default" seamlessly replace normal rpms from the base and updates repositories and must be drop in replacements for those. Otherwise they must not be declared default.
(In reply to Mattias Ellert from comment #3) > The module version of jmc is declared "default", i.e. unless you actively > disable the module version this is the version you get. I have not chosen > the activate this module, it is what you get by default. Do you have the 'jmc' module installed, though? Output of this, please: $ rpm -qa | grep module_2663 What does this command return for you? $ rpm -q javamail > I understand that if you choose to activate some module some things might > break. This is the reason for having modules in the first place. > > But no module declared "default" should be allowed to break anything. A > module declared "default" seamlessly replace normal rpms from the base and > updates repositories and must be drop in replacements for those. Otherwise > they must not be declared default. OK. I'm still trying to replicate what you are seeing, though. What are the precise steps to reproduce this? Please provide steps in terms of dnf commands. So far I was unable to :-(
(In reply to Severin Gehwolf from comment #4) > (In reply to Mattias Ellert from comment #3) > > The module version of jmc is declared "default", i.e. unless you actively > > disable the module version this is the version you get. I have not chosen > > the activate this module, it is what you get by default. > > Do you have the 'jmc' module installed, though? Output of this, please: > > $ rpm -qa | grep module_2663 > > What does this command return for you? > > $ rpm -q javamail > > > I understand that if you choose to activate some module some things might > > break. This is the reason for having modules in the first place. > > > > But no module declared "default" should be allowed to break anything. A > > module declared "default" seamlessly replace normal rpms from the base and > > updates repositories and must be drop in replacements for those. Otherwise > > they must not be declared default. > > OK. I'm still trying to replicate what you are seeing, though. What are the > precise steps to reproduce this? Please provide steps in terms of dnf > commands. So far I was unable to :-( I think if you have ever enabled or disabled the module, you can't return to the 'default' state. In a completely fresh F29 VM I can see that if I 'sudo dnf install axiom', the javamail dependency is resolved from the jmc module and there is a conflict. I have submitted PRs to drop the default stream for jmc @ https://pagure.io/releng/fedora-module-defaults/pull-request/47 https://pagure.io/releng/fedora-module-defaults/pull-request/48 This issue should no longer occur once these propagate to the system.
(In reply to Jie Kang from comment #5) > I think if you have ever enabled or disabled the module, you can't return to > the 'default' state. dnf module reset <modulename> will cancel any dnf module enable/disable <modulename>
Thanks. I've verified on F29 that JMC is no longer a default module stream and the conflicts will no longer occur. Closed as fixed for current release.