Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1760937 - dnf-yum in F30 is now higher versioned than F31+ yum's "Obsoletes" (affects upgrades)
Summary: dnf-yum in F30 is now higher versioned than F31+ yum's "Obsoletes" (affects u...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 31
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Pavla Kratochvilova
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa AcceptedBlocker
Depends On:
Blocks: F31FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2019-10-11 18:45 UTC by Adam Williamson
Modified: 2019-11-06 16:48 UTC (History)
17 users (show)

Fixed In Version: dnf-4.2.9-5.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-17 21:38:25 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Adam Williamson 2019-10-11 18:45:23 UTC 
Upgrades from F30 with dnf-yum installed to F31 currently fail unless --allowerasing is used:

https://openqa.fedoraproject.org/tests/467429#step/upgrade_run/35

"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...
Comment 1 Adam Williamson 2019-10-11 18:47:08 UTC 
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 .
Comment 2 Ben Cotton 2019-10-11 19:29:25 UTC 
+1 blocker
Comment 3 Mohan Boddu 2019-10-14 17:20:01 UTC 
+1 blocker
Comment 4 Geoffrey Marr 2019-10-14 19:10:28 UTC 
Discussed during the 2019-10-14 blocker review meeting: [0]

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)"

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-10-14/f31-blocker-review.2019-10-14-16.01.txt
Comment 5 Peter Robinson 2019-10-16 11:13:34 UTC 
There's really quite some discrepancies here:

dnf:
both f30 and f32: dnf-4.2.11-2.fc3
but
f31: dnf-4.2.9-4.fc31

libdnf:
both f30 and f32: libdnf-0.35.5-3.fc32 
but
f31: libdnf-0.35.3-5.fc31
Comment 6 Adam Williamson 2019-10-16 15:00:43 UTC 
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.
Comment 7 Peter Robinson 2019-10-16 15:02:48 UTC 
(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.
Comment 8 Bojan Smojver 2019-10-17 06:45:58 UTC 
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?
Comment 9 Fedora Update System 2019-10-17 10:43:51 UTC 
FEDORA-2019-c83c116154 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-c83c116154
Comment 10 Fedora Update System 2019-10-17 15:30:48 UTC 
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
Comment 11 Adam Williamson 2019-10-17 15:42:02 UTC 
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).
Comment 12 Peter Robinson 2019-10-17 16:08:05 UTC 
(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
> fix).

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.
Comment 13 Fedora Update System 2019-10-17 21:38:25 UTC 
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.
Comment 14 Sammy 2019-10-29 13:21:57 UTC 
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.
Comment 15 Adam Williamson 2019-10-29 15:07:59 UTC 
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/ ?
Comment 16 Sammy 2019-10-29 17:12:46 UTC 
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.
Comment 17 Craigsilva 2019-11-06 08:37:27 UTC 
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.
Comment 18 Craigsilva 2019-11-06 08:43:20 UTC 
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.
Comment 19 Adam Williamson 2019-11-06 16:48:03 UTC 
Use distro-sync, not upgrade. In fact, upgrade the correct way, with dnf system-upgrade:

https://docs.fedoraproject.org/en-US/quick-docs/upgrading/
Note You need to log in before you can comment on or make changes to this bug.