Description of problem: I can unlock a module profile version by referring a different version than the installed one. See below. Version-Release number of selected component (if applicable): dnf-2.7.5-4.fc26.modularity.1.3fb9e5c.git.8052.52e0d41None.noarch [root@0c7cc34dac27 /]# dnf module list --installed Last metadata expiration check: 0:00:22 ago on Mon Oct 23 21:48:46 2017. modularityABDE Name Stream Version Profiles ModuleA f26 2 client, default [i], ... Hint: [d]efault, [i]nstalled, [l]ocked [root@0c7cc34dac27 /]# dnf module lock ModuleA Last metadata expiration check: 0:00:29 ago on Mon Oct 23 21:48:46 2017. 'ModuleA' is locked (stream: f26, version: 2) [root@0c7cc34dac27 /]# dnf module unlock ModuleA:f26:1 Last metadata expiration check: 0:00:37 ago on Mon Oct 23 21:48:46 2017. 'ModuleA:f26:1' is unlocked
It is correct behaviour. You only need stream to unlock version, because there can be only one version locked. Same for disabling module.
I disagree. While the information is not necessary it shouldn't be blindly ignored when it is incorrect. That applies both for version and stream. Even if dnf decide to accept that it should at least notify the user that the information provided is not correct and dnf is going to use just a module name. At this particular situation is says: 'ModuleA:f26:1' is unlocked which is bogus as a different version was previously locked. It should rather say "ModuleA:f26:2" is unlocked
@QE: There is a test scenario related to this bug in module-lock-unlock-4.feature marked as @xfail. Scenario: Unlocking a module:stream:version not matching a locked module:stream:version should fail Once this bug is fixed the test scenario should be updated and enabled.
Locking of modules was dropped.