Hide Forgot
Description of problem: Disabling a module with dnf module disable doesn't disable modules that depend on it. This potentially introduces RPM-level dependency breakage for the modules that are suddenly missing dependencies. Note: Also assuming a module shouldn't be disabled if it has RPMs installed. Version-Release number of selected component (if applicable): dnf-2.7.5-19.fc28.modularity.1.3fb9e5c.git.8118.7bc81fe.noarch How reproducible: always Steps to Reproduce: 1. fresh container based on docker.io/fedora:28 (or other current F28 VM/container) with latest F28 updates, fedora-repos-modular enabled, and latest patched dnf from COPR 2. dnf module list --enabled # no modules enabled 3. dnf module enable reviewboard:2.5 4. dnf module list --enabled # reviewboard:2.5 and django:1.6 enabled 5. dnf list --installed 'python*-django*' python-markdown python-djblets ReviewBoard # no packages from django or reviewboard modules are installed 6. dnf module disable django 7. dnf module list --enabled Actual results: django:1.6 no longer enabled, but reviewboard:2.5 still enabled Expected results: neither django:1.6 nor reviewboard:2.5 enabled Additional info:
Disabling dependency modules is bit dangerous, you can disable module that is still needed by other enabled module. We need proper dependency solving. I propose this to be implemented in libdnf, after F28 release.
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
The problem was solved by transparent modular solving. It will be fixed in dnf-3.6.0