$ dnf install ruby
$ dnf module install ruby:2.6/default
$ dnf mark group ruby
$ dnf module remove ruby:2.6/default
$ dnf module enable NAME:STREAM
$ dnf module enable nodejs:8
$ dnf module install NAME
$ dnf module install NAME:STREAM
$ dnf module install NAME/PROFILE
$ dnf module install NAME:STREAM/PROFILE
$ dnf module install nodejs:8
$ dnf module install mongodb/client
$ dnf module list
$ dnf module remove MODULE:STREAM/PROFILE
$ dnf module switch-to NAME:STREAM
$ dnf module switch-to nodejs:10
$ dnf module switch-to nodejs:8
$ dnf remove nodejs
$ dnf module reset nodejs:8
$ dnf module enable nodejs:10
$ dnf install nodejs
An example, to switch from Node.js 10 to Node.js 8, run:
An example, to switch from Node.js 8 to Node.js 10, run:
Because modules use the __group__ reason, which is weaker than __user__ used by the `dnf install` command, the package stays on the system after running the `dnf module remove` command. "Downgrading" it to __group__, however, makes the `dnf module remove` remove it as well.
broken dependencies when switching module streams without removing the installed content
Enabling modules
First DNF is trying to upgrade or downgrade the existing installed software. It will not remove the existing software during the execution of the `reset` argument. The `reset` only disables the enabled stream of a module. The NEVRAs of the RPM files in the module stream can have different versions from the installed software (newer or older) and also from other streams from the same module. The runtime dependencies can be different between RPM packages from different module streams.