Description of problem: `dnf downgrade <nevra>` fails while `dnf install <nevra>` works for older version of already installed package Version-Release number of selected component (if applicable): dnf-0.6.3-2.fc21 How reproducible: always Steps to Reproduce: 1. rpm -q boost-system boost-thread 2. dnf downgrade boost-system-1.55.0-4.fc21.x86_64 boost-thread-1.55.0-4.fc21.x86_64 3. dnf install boost-system-1.55.0-4.fc21.x86_64 boost-thread-1.55.0-4.fc21.x86_64 Actual results: # rpm -q boost-system boost-thread boost-system-1.55.0-8.fc21.x86_64 boost-thread-1.55.0-8.fc21.x86_64 # dnf downgrade boost-system-1.55.0-4.fc21.x86_64 boost-thread-1.55.0-4.fc21.x86_64 No match for available package: boost-system-1.55.0-4.fc21.x86_64 No match for available package: boost-thread-1.55.0-4.fc21.x86_64 # dnf install boost-system-1.55.0-4.fc21.x86_64 boost-thread-1.55.0-4.fc21.x86_64 Dependencies resolved. ========================================================================================================== Package Arch Version Repository Size ========================================================================================================== Downgrading: boost-system x86_64 1.55.0-4.fc21 fedora 44 k boost-thread x86_64 1.55.0-4.fc21 fedora 68 k Transaction Summary ========================================================================================================== Downgrade 2 Packages Total download size: 112 k Is this ok [y/N]: y Expected results: both `dnf downgrade` and `dnf install` works the same way in this situation Additional info:
As I said on IRC, this is NOTABUG. And also "downgrade" behaves as documented. Since DNF's documentation defines what DNF should do, there is no reason why this should be considered a bug. Since there is already a way how to downgrade to a specific version, the only reason why would one need to support this redundancy is to be compatible with YUM. Bug DNF is not a drop-in replacement of YUM. So, the only problem I can see here is that we do not explicitly mention the difference from YUM in our documentation. If anyway someone needs a second command that does the same thing, I would rather implement a "downgrade-to" command (similarly to YUM's upgrade-to) because if we add the "downgrade to" behaviour in "downgrade" command, we will introduce just another ambiguity since e.g. in case of installonly packages it won't be clear whether "dnf downgrade kernel-3.18.3-201.fc21" means "downgrade kernel-3.18.3-201.fc21" or "downgrade to kernel-3.18.3-201.fc21". But still, there wasn't mentioned any use case in which "dnf install" doesn't work while "dnf downgrade" does and features needs to be supported by a use case. And another reason is that I'd argue that reading "dnf downgrade foo-2" as an English sentence clearly means that I want to downgrade foo-2, not downgrade *to* foo-2. I'd be happy if anyone can give me a rational reason/usecase why we need this redundancy other then "because that's what YUM does" or at least prove that my arguments are wrong.
PR: https://github.com/rpm-software-management/dnf/pull/243
dnf-plugins-core-0.1.7-1.fc22,hawkey-0.5.5-1.fc22,dnf-1.0.0-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/dnf-plugins-core-0.1.7-1.fc22,hawkey-0.5.5-1.fc22,dnf-1.0.0-1.fc22
Package dnf-plugins-core-0.1.7-1.fc22, hawkey-0.5.5-1.fc22, dnf-1.0.0-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnf-plugins-core-0.1.7-1.fc22 hawkey-0.5.5-1.fc22 dnf-1.0.0-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-7483/dnf-plugins-core-0.1.7-1.fc22,hawkey-0.5.5-1.fc22,dnf-1.0.0-1.fc22 then log in and leave karma (feedback).
dnf-plugins-core-0.1.7-1.fc22, hawkey-0.5.5-1.fc22, dnf-1.0.0-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.