Description of problem: update a newly installed f36 system, reboot it and then: [lnie@localhost-live ~]$ sudo dnf system-upgrade download --refresh --releasever=37 [sudo] password for lnie: Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y Fedora 37 - x86_64 55 kB/s | 35 kB 00:00 Fedora 37 openh264 (From Cisco) - x86_64 745 B/s | 989 B 00:01 Fedora Modular 37 - x86_64 24 kB/s | 35 kB 00:01 Fedora 37 - x86_64 - Updates 8.8 kB/s | 4.6 kB 00:00 Fedora Modular 37 - x86_64 - Updates 17 kB/s | 4.5 kB 00:00 no group 'arm-tools' from environment 'workstation-product-environment' No match for group package "authselect-compat" No match for group package "reiserfs-utils" No match for group package "google-noto-sans-osmanya-vf-fonts" No match for group package "google-noto-sans-cuneiform-vf-fonts" No match for group package "drehatlas-xaporho-fonts" No match for group package "google-noto-sans-lycian-vf-fonts" No match for group package "yanone-tagesschrift-fonts" No match for group package "ubuntu-title-fonts" No match for group package "google-noto-serif-tangut-vf-fonts" No match for group package "google-noto-sans-soyombo-vf-fonts" No match for group package "google-noto-sans-warang-citi-vf-fonts" No match for group package "google-noto-sans-anatolian-hieroglyphs-vf-fonts" No match for group package "google-noto-sans-shavian-vf-fonts" No match for group package "google-noto-sans-mro-vf-fonts" No match for group package "google-noto-sans-takri-vf-fonts" No match for group package "chrome-gnome-shell" No match for group package "sil-scheherazade-fonts" No match for group package "google-noto-sans-ogham-vf-fonts" No match for group package "qgnomeplatform" No match for group package "kanjistrokeorders-fonts" No match for group package "google-noto-sans-thai-looped-vf-fonts" No match for group package "vollkorn-fonts" No match for group package "google-noto-sans-elymaic-vf-fonts" No match for group package "tlomt-junction-fonts" No match for group package "google-noto-sans-carian-vf-fonts" No match for group package "google-noto-sans-gothic-vf-fonts" No match for group package "google-noto-sans-marchen-vf-fonts" No match for group package "google-noto-sans-hatran-vf-fonts" No match for group package "google-noto-sans-ugaritic-vf-fonts" No match for group package "google-noto-sans-nabataean-vf-fonts" No match for group package "google-noto-sans-buginese-vf-fonts" No match for group package "google-noto-sans-linear-b-vf-fonts" No match for group package "google-noto-sans-egyptian-hieroglyphs-vf-fonts" No match for group package "google-noto-sans-cypriot-vf-fonts" No match for group package "google-noto-sans-buhid-vf-fonts" No match for group package "drehatlas-warender-bibliothek-fonts" No match for group package "bcm283x-firmware" No match for group package "google-noto-sans-lydian-vf-fonts" No match for group package "google-noto-sans-wancho-vf-fonts" No match for group package "google-noto-sans-linear-a-vf-fonts" No match for group package "google-noto-sans-tagbanwa-vf-fonts" No match for group package "google-noto-sans-vai-vf-fonts" No match for group package "xorg-x11-drv-armsoc" No match for group package "google-noto-sans-lao-looped-vf-fonts" No match for group package "polarsys-b612-sans-fonts" No match for group package "google-noto-sans-deseret-vf-fonts" No match for group package "google-noto-sans-avestan-vf-fonts" No match for group package "google-noto-sans-imperial-aramaic-vf-fonts" No match for group package "google-noto-sans-devanagari-ui-vf-fonts" No match for group package "google-noto-sans-yi-vf-fonts" No match for group package "culmus-shofar-fonts" No match for group package "google-noto-sans-mandaic-vf-fonts" No match for group package "google-noto-sans-phoenician-vf-fonts" No match for group package "google-noto-sans-multani-vf-fonts" No match for group package "google-noto-sans-mayan-numerals-vf-fonts" Error: Problem 1: package webkit2gtk3-2.38.1-1.fc36.x86_64 requires libicui18n.so.69()(64bit), but none of the providers can be installed - package webkit2gtk3-2.38.1-1.fc36.x86_64 requires libicuuc.so.69()(64bit), but none of the providers can be installed - libicu-69.1-6.fc36.x86_64 does not belong to a distupgrade repository - problem with installed package webkit2gtk3-2.38.1-1.fc36.x86_64 Problem 2: package boost-locale-1.78.0-9.fc37.x86_64 requires libicuuc.so.71()(64bit), but none of the providers can be installed - package boost-locale-1.78.0-9.fc37.x86_64 requires libicui18n.so.71()(64bit), but none of the providers can be installed - package boost-locale-1.78.0-9.fc37.x86_64 requires libicudata.so.71()(64bit), but none of the providers can be installed - cannot install both libicu-71.1-2.fc37.x86_64 and libicu-69.1-6.fc36.x86_64 - problem with installed package boost-locale-1.76.0-12.fc36.x86_64 - package webkit2gtk3-jsc-2.38.1-1.fc36.x86_64 requires libicui18n.so.69()(64bit), but none of the providers can be installed - package webkit2gtk3-jsc-2.38.1-1.fc36.x86_64 requires libicuuc.so.69()(64bit), but none of the providers can be installed - boost-locale-1.76.0-12.fc36.x86_64 does not belong to a distupgrade repository - problem with installed package webkit2gtk3-jsc-2.38.1-1.fc36.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages) FYI:only affects workstation failed job: https://beaker.engineering.redhat.com/jobs/7191786(x86_64) https://beaker.engineering.redhat.com/jobs/7191575(aarch64) succeed job(during RC1.4): https://beaker.engineering.redhat.com/jobs/7169998 https://beaker.engineering.redhat.com/jobs/7169420 Checked on local machine,see the same symptom Version-Release number of selected component (if applicable): dnf-4.14.0-1.fc36.noarch How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Please note you will be able to upgrade the system successfully if you add --allowerasing option during download process
Proposed as a Freeze Exception for 37-final by Fedora user lnie using the blocker tracking app because: seems affects: For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from a fully updated, clean default installation of each of the last two stable Fedora releases with that package set installed
I suspect the problem here is not RC-1.4 vs. RC-1.5, but a change in F36: webkit2gtk3 went from 2.38.0 to 2.38.1 recently. I rather suspect something is supposed to obsolete it in F37, but the bounds on the obsolete are < 2.38.1 or something like that. Let's see... ...yup, that's exactly the problem: https://koji.fedoraproject.org/koji/rpminfo?rpmID=32109959 webkit2gtk4.0 obsoletes webkit2gtk3, but the webkit2gtk4.0 in F37 stable is a 2.38.0 build and only obsoletes "webkit2gtk3 < 2.38.0-3.fc37". https://bodhi.fedoraproject.org/updates/FEDORA-2022-3bc81cae3b would fix this if we push it stable.
FEDORA-2022-3bc81cae3b has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-3bc81cae3b
*** This bug has been marked as a duplicate of bug 2138910 ***
Note I'm fine with a freeze exception to fix this, but we'll need a second one soon because 2.38.2 will be out any day now, before freeze lifts.
Can we not just bump the bound on the obsolete to something higher that's not tied to the build version? Or does it have to be tied?
(In reply to Michael Catanzaro from comment #6) > Note I'm fine with a freeze exception to fix this, but we'll need a second > one soon because 2.38.2 will be out any day now, before freeze lifts. Closing this bug and the other one as well means it's off our freeze exception radar. So if you think this needs an FE (I'm not really sure), one of those bugs must be reopened.
(In reply to Adam Williamson from comment #7) > Can we not just bump the bound on the obsolete to something higher that's > not tied to the build version? Or does it have to be tied? That would work, except the packaging guidelines https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages require the Obsoletes in its current form "so that there is a clean upgrade path but without gratuitously polluting the version space upwards." It's a bad idea, as you've noticed, because it breaks during freeze periods. We'll have the same problem next release cycle when webkit2gtk5.0 gets renamed to webkitgtk6.0. > Closing this bug and the other one as well means it's off our freeze exception radar. So if you think this needs an FE (I'm not really sure), one of those bugs must be reopened. I don't care tbh. Fedora does not attempt to maintain upgrade paths anymore, so I'd say an upgrade without --allowerasing is just not generally expected to work anymore, and users should not be encouraged to attempt it. That should really be the default. But since it's actually documented as the recommended way to upgrade, a freeze exception does make sense. I'll request one again once the 2.38.2 update is ready. The 2.38.1 update will be obsoleted very soon regardless.
The word "gratuitously" there is significant, too. If for instance it's extremely unlikely that we could even possibly want the name 'webkit2gtk3' back without a new major release of webkitgtk, it would seem reasonable to me to make the bound "< 3". It's really a "don't shoot yourself in the foot in case you want the original name back later" rule.