Hide Forgot
I just tried to call dnf update in my rawhide machine and this came out of it: -------------------------------------------------------------------------- # dnf update --refresh Fedora 33 openh264 (From Cisco) - x86_64 180 B/s | 543 B 00:03 Fedora - Modular Rawhide - Developmental packag 10 kB/s | 14 kB 00:01 Fedora - Modular Rawhide - Developmental packag 200 kB/s | 160 kB 00:00 Fedora - Rawhide - Developmental packages for t 18 kB/s | 14 kB 00:00 Fedora - Rawhide - Developmental packages for t 530 kB/s | 1.7 MB 00:03 Dependencies resolved. Problem: package fedora-obsolete-packages-33-6.noarch obsoletes python2-backports-functools_lru_cache < 1.5-7 provided by python2-backports-functools_lru_cache-1.5-6.fc31.noarch - package python2-soupsieve-1.9.2-2.fc32.noarch requires python2.7dist(backports.functools-lru-cache), but none of the providers can be installed - package python2-soupsieve-1.9.2-2.fc32.noarch requires python2dist(backports.functools-lru-cache), but none of the providers can be installed - cannot install the best update candidate for package exaile-4.0.0-3.fc31.noarch - problem with installed package python2-soupsieve-1.9.2-2.fc32.noarch Nothing to do. Complete! -------------------------------------------------------------------------- I'd say that the fedora-obsolete-packages package update should not break update path. But maybe I'm wrong. Using `dnf update --allowerasing --best` works [1], even it's not suggested by dnf (it is sometimes suggested to use either of the options, or it used to be in the past). [1] From dnf: Installing dependencies: python3-mutagen noarch 1.43.0-2.fc32 rawhide 357 k replacing python2-mutagen.noarch 1.42.0-7.fc32 Removing dependent packages: exaile noarch 4.0.0-3.fc31 @rawhide 7.5 M python2-backports x86_64 1.0-17.fc31 @rawhide 638 python2-backports-functools_lru_cache noarch 1.5-6.fc31 @rawhide 17 k python2-beautifulsoup4 noarch 4.8.0-2.fc32 @rawhide 917 k python2-cddb x86_64 1.4-26.fc31 @rawhide 59 k python2-gobject x86_64 3.34.0-3.fc32 @rawhide 24 k python2-gobject-base x86_64 3.34.0-3.fc32 @rawhide 1.3 M python2-gstreamer1 x86_64 1.16.1-1.fc32 @rawhide 436 k python2-soupsieve noarch 1.9.2-2.fc32 @rawhide 242 k Transaction Summary ================================================================================ Install 1 Package Remove 9 Packages Interestingly, it doesn't mention fedora-obsolete-packages at all.
So the idea is that fedora-obsolete-packages obsoletes packages that would otherwise block the break update path. However, if not all of such packages are obsoleted, it looks like it's fedora-obsolete-packages that breaks it. To fix this, it must obsolete all of the following removed packages: exaile noarch 4.0.0-3.fc31 @rawhide 7.5 M python2-backports x86_64 1.0-17.fc31 @rawhide 638 python2-backports-functools_lru_cache noarch 1.5-6.fc31 @rawhide 17 k python2-beautifulsoup4 noarch 4.8.0-2.fc32 @rawhide 917 k python2-cddb x86_64 1.4-26.fc31 @rawhide 59 k python2-gobject x86_64 3.34.0-3.fc32 @rawhide 24 k python2-gobject-base x86_64 3.34.0-3.fc32 @rawhide 1.3 M python2-gstreamer1 x86_64 1.16.1-1.fc32 @rawhide 436 k python2-soupsieve noarch 1.9.2-2.fc32 @rawhide 242 k Yet it doesn't, it only obsoletes: exaile < 4.0.0-4 python2-backports < 1.0-18 python2-backports-functools_lru_cache < 1.5-7 python2-beautifulsoup4 < 4.8.1-2 python2-cddb < 1.4-27 python2-gobject < 3.34.0-4 python2-gobject-base < 3.34.0-4 python2-gstreamer1 < 1.16.2-2 python2-soupsieve < 1.9.2-2 I see that python2-soupsieve has a bad version obsoleted and that the bug. > Interestingly, it doesn't mention fedora-obsolete-packages at all. Yes, because it removes python2-soupsieve and so there is no more problem. I'll fix this in rawhide and Fedora 32.
(In reply to Miro Hrončok from comment #1) > > Interestingly, it doesn't mention fedora-obsolete-packages at all. > > Yes, because it removes python2-soupsieve and so there is no more problem. Not really 'yes' from my point of view, but I do not know how this is supposed to work in reality. What I expect is that when I install a package, its provides/obsoletes/requires are all taken into consideration and necessary steps are taken immediately, which didn't happen here. If I understand my situation correctly, then the fedora-obsolete-packages had been updated in some previous 'dnf update' call, and only the next 'dnf update' call begun to obsolete already installed packages. I'm pretty sure these had been installed when fedora-obsolete-packages had been installed/updated, I do not install python packages on my own usually. That's the reason why I'd expect seeing fedora-obsolete-packages mentioned in the list of to-be-done changes in the [1] from the comment #0.
Note that fedora-obsolete-packages self removes itself after the transaction, so if there is no problem, you don't see it listed at all.
(In reply to Miro Hrončok from comment #3) > Note that fedora-obsolete-packages self removes itself after the > transaction, so if there is no problem, you don't see it listed at all. Interesting. I hope it's not downloaded every time I run 'dnf update', that would feel like a waste of bandwidth.
Honestly, I don't really know if it is downloaded at all. There are two scenarios I can think of: 1) It's only downloaded if you have packages installed that are obsoleted by f-o-p. It obsoletes them and goes away. 2) Like the above but since only the metadata are needed, the actual RPM package is never downloaded. I think the second point is more plausible, but I have not studied the libsolv/dnf code.
Okay, that's fine. The most surprising thing, to me, is that it doesn't behave like a regular package (not installed packages do not influence the installation). Everything else is just an implementation detail.
fedora-obsolete-packages-32-43 has been pushed to the Fedora 32 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-2020-4665f9ec2b
FEDORA-2020-4665f9ec2b has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.