Description of problem: After updating to Fedora 30 my system is in a state where a few maven packages are stuck at their Fedora 29 versions and can not be updated to the Fedora 30 versions: # dnf update Last metadata expiration check: 5:18:33 ago on Thu May 2 17:56:10 2019. Dependencies resolved. Problem 1: package maven-wagon-ssh-common-3.2.0-2.fc30.noarch requires mvn(org.apache.maven.wagon:wagon-provider-api) = 3.2.0, but none of the providers can be installed - cannot install the best update candidate for package maven-wagon-ssh-common-3.1.0-2.fc29.noarch - package maven-wagon-provider-api-3.2.0-2.fc30.noarch is excluded Problem 2: package maven-wagon-ssh-3.2.0-2.fc30.noarch requires mvn(org.apache.maven.wagon:wagon-provider-api) = 3.2.0, but none of the providers can be installed - cannot install the best update candidate for package maven-wagon-ssh-3.1.0-2.fc29.noarch - package maven-wagon-provider-api-3.2.0-2.fc30.noarch is excluded Problem 3: package maven-wagon-http-lightweight-3.2.0-2.fc30.noarch requires mvn(org.apache.maven.wagon:wagon-provider-api) = 3.2.0, but none of the providers can be installed - cannot install the best update candidate for package maven-wagon-http-lightweight-3.1.0-2.fc29.noarch - package maven-wagon-provider-api-3.2.0-2.fc30.noarch is excluded Problem 4: package maven-resolver-test-util-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 - cannot install the best update candidate for package maven-resolver-test-util-1:1.1.1-3.fc29.noarch - package maven-resolver-spi-1:1.3.1-2.fc30.noarch is excluded ================================================================================ Package Arch Version Repository Size ================================================================================ Skipping packages with broken dependencies: maven-resolver-test-util noarch 1:1.3.1-2.fc30 fedora 59 k maven-wagon-http-lightweight noarch 3.2.0-2.fc30 fedora 25 k maven-wagon-ssh noarch 3.2.0-2.fc30 fedora 38 k maven-wagon-ssh-common noarch 3.2.0-2.fc30 fedora 31 k Transaction Summary ================================================================================ Skip 4 Packages Nothing to do. Complete! This is due to the fact that some of the maven packages provided by the maven module, which is declared default, do not provide all the subpackages the coresponding non-module rpm package provides. The maven-resolver package in the module provides: maven-resolver-api maven-resolver-connector-basic maven-resolver-impl maven-resolver-spi maven-resolver-transport-file maven-resolver-transport-http maven-resolver-transport-wagon maven-resolver-util The maven-resolver non-module package in addition provides: maven-resolver maven-resolver-javadoc maven-resolver-test-util maven-resolver-transport-classpath The maven-wagon package in the module provides: maven-wagon-file maven-wagon-http maven-wagon-http-shared maven-wagon-provider-api The maven-wagon non-module package in addition provides: maven-wagon maven-wagon-ftp maven-wagon-http-lightweight maven-wagon-javadoc maven-wagon-providers maven-wagon-scm maven-wagon-ssh maven-wagon-ssh-common maven-wagon-ssh-external Since the module is declared default, the packages in the module override the package from the normal rpm, and the packages from the normal rpm are not available for installation (dnf says they are excluded). For the packages that are not provided by the module, the normal rpm version is not overridden. However, they are not installable since they depends on the non-module version of packages built from the same srpm (as they should according to the guidelines). A srpm built as part of a module declared default must provide all subpackages that the non-module srpm builds, or alternatively obsolete the subpackages it does not build (this choice is only acceptable if there are no other packages with dependencies or build dependencies on the subpackage). Otherwise the subpackages provided by the normal rpm that are not excluded by the module become uninstallable. Version-Release number of selected component (if applicable): maven-wagon-3.1.0-1.module_f28+3939+dc18cd75 maven-wagon-3.1.0-2.fc29 maven-wagon-3.2.0-2.fc30 maven-resolver-1.1.1-2.module_f28+3939+dc18cd75 maven-resolver-1.1.1-3.fc29 maven-resolver-1.3.1-2.fc30 How reproducible: Steps to Reproduce: 1. Try to install one of the affected packages in Fedora 30 Actual results: Installation/upgrade failure Expected results: Installation/upgrade success
As I understand this, the modular version of maven (or the modularity terminology) is hurting the non-modular version of maven. Is there anything the non modular maven package can do to prevent this from happening? Should this be recategorized as modularity bug?
> or the modularity terminology s/terminology/technology
I am aware of the situation and I am working on a fix. Future versions of maven modules will be parallel-installable with ursine maven.
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
According to current modules policy [1] modular packages can only exist as alternative versions. Since Maven 3.6 exists as non-modular package in Fedora, modular Maven 3.6 is not allowed according to the policy. [1] https://docs.fedoraproject.org/en-US/modularity/policies/