Felix Miata:
[mc-4.8.18 has been broken since release, so I locked 4.8.17]
# grep RETT /etc/os-release
PRETTY_NAME="Fedora 26 (Twenty Six)"
# dnf versionlock list
Last metadata expiration check: 1:33:30 ago on Thu Mar 23 16:44:17 2017 EDT.
mc-1:4.8.17-2.fc25.*
# dnf list mc
Last metadata expiration check: 1:33:33 ago on Thu Mar 23 16:44:17 2017 EDT.
Installed Packages
mc.x86_64 1:4.8.17-2.fc25 @System
# dnf check-update mc
Last metadata expiration check: 1:33:35 ago on Thu Mar 23 16:44:17 2017 EDT.
#
# dnf versionlock delete mc
Last metadata expiration check: 1:41:52 ago on Thu Mar 23 16:44:17 2017 EDT.
Deleting versionlock for: mc-1:4.8.17-2.fc25.*
# dnf list mc
Last metadata expiration check: 1:41:58 ago on Thu Mar 23 16:44:17 2017 EDT.
Installed Packages
mc.x86_64 1:4.8.17-2.fc25 @System
Available Packages
mc.x86_64 1:4.8.18-4.fc26 fedora
# dnf check-update mc
Last metadata expiration check: 1:42:08 ago on Thu Mar 23 16:44:17 2017 EDT.
mc.x86_64 1:4.8.18-4.fc26 fedora
#
How is one expected to discover via dnf when (18 day old) 4.8.19
finally becomes available and time to delete the lock has arrived?
Is this a bug in the versionlock plugin? DNF itself? Expected
behavior?
If you locked 4.8.17 then dnf ignores all other versions.
That's how versionlock is supposed to work, i.e. expected behavior.
If you want to ignore broken version it's better to put just this one to exclude.
--
Michael Mráka
System Management Engineering, Red Hat