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 2139284 - webkit2gtk3 is improperly obsoleted
Summary: webkit2gtk3 is improperly obsoleted
Keywords:
Status: CLOSED DUPLICATE of bug 2138910
Alias: None
Product: Fedora
Classification: Fedora
Component: webkit2gtk3
Version: 37
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michael Catanzaro
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F37FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2022-11-02 05:06 UTC by lnie
Modified: 2022-11-02 15:15 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-02 14:22:38 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description lnie 2022-11-02 05:06:39 UTC 
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:
Comment 1 lnie 2022-11-02 05:29:31 UTC 
Please note you will be able to upgrade the system successfully if you add --allowerasing option during download process
Comment 2 Fedora Blocker Bugs Application 2022-11-02 05:29:43 UTC 
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
Comment 3 Adam Williamson 2022-11-02 06:11:02 UTC 
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.
Comment 4 Fedora Update System 2022-11-02 06:11:27 UTC 
FEDORA-2022-3bc81cae3b has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-3bc81cae3b
Comment 5 Michael Catanzaro 2022-11-02 14:22:38 UTC 

*** This bug has been marked as a duplicate of bug 2138910 ***
Comment 6 Michael Catanzaro 2022-11-02 14:25:41 UTC 
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.
Comment 7 Adam Williamson 2022-11-02 14:45:54 UTC 
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?
Comment 8 Kamil Páral 2022-11-02 14:46:52 UTC 
(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.
Comment 9 Michael Catanzaro 2022-11-02 15:10:29 UTC 
(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.
Comment 10 Adam Williamson 2022-11-02 15:15:52 UTC 
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.
Note You need to log in before you can comment on or make changes to this bug.