Upgrades from F30 with dnf-yum installed to F31 currently fail unless --allowerasing is used:
"Problem: package dnf-yum-4.2.11-2.fc30.noarch requires dnf = 4.2.11-2.fc30, but none of the providers can be installed"
The real problem here is that the F31 package 'yum' is supposed to obsolete F30 package 'dnf-yum', but the versioning has got out of whack. In current F31, we have yum-4.2.9-4.fc31.noarch , which has this:
[adamw@adam mutter (master *+%)]$ rpm -q --obsoletes yum
dnf-yum < 4.2.9-4.fc31
but the dnf-yum in F30 has gone past that version, it's now 4.2.11-2.fc30 as we can see above. So the obsolete is no longer kicking in.
We need to at least bump the Obsoletes line in F31. We could consider taking yum 4.2.11 into F31 as well, I guess, but it's now past the Final freeze...
Proposing as a Final blocker - per openQA testing this seems to affect all default release-blocking package sets, even a minimal F30 install has dnf-yum installed it seems. In the past we've blocked on upgrade issues that can only be bypasses by using --allowerasing .
Discussed during the 2019-10-14 blocker review meeting: 
The decision to classify this bug as an "AcceptedBlocker" was made as it violates the Beta upgrade criteria, specifically the footnote:
"The upgraded system must include all packages that would be present on the system after a default installation from install media, plus any packages the user previously had (minus any obsolete content)"
There's really quite some discrepancies here:
both f30 and f32: dnf-4.2.11-2.fc3
both f30 and f32: libdnf-0.35.5-3.fc32
yeah, I know. I've heard that the DNF team intends to leave it this way until F31 GA then catch up with a post-release update but I'm not 100% sure. The discrepancy isn't inherently a problem, I don't think, we can have the "older" yum obsolete the "newer" dnf-yum without problems, and I don't think it should cause any other problems either.
(In reply to Adam Williamson from comment #6)
> yeah, I know. I've heard that the DNF team intends to leave it this way
> until F31 GA then catch up with a post-release update but I'm not 100% sure.
> The discrepancy isn't inherently a problem, I don't think, we can have the
> "older" yum obsolete the "newer" dnf-yum without problems, and I don't think
> it should cause any other problems either.
The problem is they don't have release branches and there's other problems so it then makes other possible fixes more problematic.
I bumped into this when trying to update to F31 with dnf. I mean, it's easy enough to remove the offending package and carry on.
But, my question here is, is there a technical reason this particular dnf version has to be used for F31? I mean, it shouldn't be that difficult to rebuild, right?
FEDORA-2019-c83c116154 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-c83c116154
dnf-4.2.9-5.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-c83c116154
Bojan: there's no technical reason I don't think, no. But we're in the Final freeze for F31 release and we don't just bump to a new release during freeze unless we have a specific reason to do so (a critical bug the update would fix).
(In reply to Adam Williamson from comment #11)
> Bojan: there's no technical reason I don't think, no. But we're in the Final
> freeze for F31 release and we don't just bump to a new release during freeze
> unless we have a specific reason to do so (a critical bug the update would
Agreed, moving forward we need to work with the dnf team to work out why updates that were being pushed to F-30 and rawhide weren't being pushed to F-31, looking at koji buids they sort of stopped early September while F-30 and F-32 continued on.
dnf-4.2.9-5.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
I am just installing fc31 manually with dnf from fc30 and "dnf update dnf libdnf" still thinks that the fc30 ones are newer.
I had to manually bring in many dependent packages and remove some rpms to install the new dnf, rpm etc by brute force.
That's a different issue. And that's why the officially-recommended upgrade tools use distro-sync, not update. Why aren't you upgrading as recommended at https://docs.fedoraproject.org/en-US/quick-docs/upgrading/ ?
Thanks, old habits die hard....I build many of my own packages and dnf upgrade tells me what is changing
more clearly as I manually fix conflicts etc.
Newish to Fedora and ran into this bug: yum-4.2.9-5.fc31.noarch requires dnf = 4.2.9-5.fc31, but none of the providers can be installed - none of the suggested commands resolved it so spent a couple of hours attempting to fix it but ended up in dependency hell - at least this bug explains the dilemma. Might be useful to update known issues.
A futher comment: sudo dnf upgrade --refresh
- cannot install both dnf-4.2.9-5.fc31.noarch and dnf-4.2.11-2.fc30.noarch
- cannot install the best update candidate for package dnf-yum-4.2.11-2.fc30.noarch
- problem with installed package dnf-4.2.11-2.fc30.noarch
Seems as though dnf-4.2.9-5.fc31.noarch does not resolve it.
Use distro-sync, not upgrade. In fact, upgrade the correct way, with dnf system-upgrade: