Description of problem: Problem 1: package php-imap-7.4.20-1.fc33.x86_64 requires php-common(x86-64) = 7.4.20-1.fc33, but none of the providers can be installed - php-common-7.4.20-1.fc33.x86_64 does not belong to a distupgrade repository - problem with installed package php-imap-7.4.20-1.fc33.x86_64 Version-Release number of selected component (if applicable): upgrading from F33 to F34 How reproducible: Steps to Reproduce: 1. dnf system-upgrade --releasever=34 --skip-broken -y 2. nextcloud needs php-imap on F33 but not in F34 ... 3. Actual results: php-imap be obsoleted by fedora-obsolete-packages Expected results: clean upgrade Additional info:
JFTR: to fix the problem I runned `dnf remove php-imap` which removed nextcloud . And I also had problems with rdma-core.i686 [1], I needed remove rdma-core.i686 before upgrade [2] and install wine after the upgrade [3] [1] Problem 2: rdma-core-35.0-1.fc33.i686 has inferior architecture - rdma-core-35.0-1.fc33.x86_64 does not belong to a distupgrade repository - problem with installed package rdma-core-35.0-1.fc33.i686 [2] dnf remove rdma-core.i686 A remover: rdma-core i686 35.0-1.fc33 @updates 115 k Removing dependent packages: libibverbs i686 35.0-1.fc33 @updates 994 k libpcap i686 14:1.10.0-1.fc33 @updates 404 k wine x86_64 6.9-1.fc33 @updates 0 wine-core i686 6.9-1.fc33 @updates 474 M wine-dxvk i686 1.8.1-2.fc33 @updates 49 M wine-dxvk x86_64 1.8.1-2.fc33 @updates 61 M wine-dxvk-d3d9 i686 1.8.1-2.fc33 @updates 14 M wine-dxvk-d3d9 x86_64 1.8.1-2.fc33 @updates 17 M [3] dnf install wine nextcloud ======================================================================================================================== Package Architecture Version Repository Size ======================================================================================================================== Installing: nextcloud noarch 20.0.8-2.fc34 fedora 84 M wine x86_64 6.10-1.fc34 updates 12 k A instalar depend??ncias: SDL2_net x86_64 2.0.1-13.fc34 fedora 20 k fluid-soundfont-gm noarch 3.1-24.fc34 fedora 124 M libibverbs i686 35.0-1.fc34 updates 374 k libpcap i686 14:1.10.0-1.fc34 fedora 182 k nextcloud-httpd noarch 20.0.8-2.fc34 fedora 12 k nextcloud-mysql noarch 20.0.8-2.fc34 fedora 10 k opusfile x86_64 0.12-3.fc34 fedora 54 k wine-core i686 6.10-1.fc34 updates 80 M wine-dxvk i686 1.8.1-2.fc34 updates 12 M wine-dxvk-d3d9 i686 1.8.1-2.fc34 updates 3.5 M Installing weak dependencies: dosbox-staging x86_64 0.76.0-2.fc34 fedora 1.4 M wine-dxvk x86_64 1.8.1-2.fc34 updates 12 M wine-dxvk-d3d9 x86_64 1.8.1-2.fc34 updates 3.5 M
This just bit me too, and still matters for F35. php-imap is _widely_ used for authentication purposes, even by stuff that continues to be included with Fedora.
It doesn't sound like fedora-obsolete-packages is the right solution here. And the thing about rdma-core seems completely unrelated to php-imap or indeed anything that fedora-obsolete-packages could fix.
dnf wrote: "Package php-imap-7.4.20-1.fc33.x86_64 requires php-common(x86-64) = 7.4.20-1.fc33, but none of the providers can be installed" , if php-imap is added to fedora-obsolete-packages does not fix it ? rdma-core seems it is fixed with: https://src.fedoraproject.org/rpms/rdma-core/c/5fa6954dc254243b95d3201cabf817b5d1edc28e?branch=rawhide
It wouldn't fix it as long as other maintained packages in the distribution are depending on php-imap.
Given that php-imap has been dropped as of F34 (and is also missing from F35) by definition nothing in Fedora 34+ is "depending" on php-imap. By that definition it should have been added to fedora-obsolete-packages, especially when it's now documented as breaking upgrades to F35... imap is often usually one of several authentication options provided by php applications, something that has to be enabled by users as part of local configuration but rarely required directly. Even in F33 only one package relied on php-imap, and that was only for a test harness not actually used at runtime. Upstream PHP has *not* deprecated or dropped php-imap yet, though it has been talked about. It is my understanding that Fedora dropped php-imap when uw-imap was intentionally dropped, and it's not coming back. Disappointing that this doesn't seem to have actually been directly documented anywhere, though various upstreams that relied upon php-imap have started switching to alternatives. Meanwhile. I've been moving my use of php-imap to the PEAR Net_IMAP module instead, which seems to work well enough so far.
(In reply to Solomon Peachy from comment #6) > It is my understanding that Fedora dropped php-imap when uw-imap was > intentionally dropped, and it's not coming back. Disappointing that this > doesn't seem to have actually been directly documented anywhere, though > various upstreams that relied upon php-imap have started switching to > alternatives. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3EXXGOGZUWLY3T4A4XO6UIK3MNMAJ2CK/ > > Meanwhile. I've been moving my use of php-imap to the PEAR Net_IMAP module > instead, which seems to work well enough so far. https://src.fedoraproject.org/rpms/php-pear-Net-IMAP seems an excellent alternative (In reply to Jason Tibbitts from comment #5) > It wouldn't fix it as long as other maintained packages in the distribution > are depending on php-imap. No , not a single package on F35 depends on php-imap. nextcloud, php-phpmailer6 and mrbs drop the dependency and the others packages (that depends on php-imap) have also been retired.
Hi, BTW this report is about an upgrade from F33 to F34, uw-imap (php-imap) was retired on F34 dnf repoquery --release 34 php-imap (empty result)
Tibbs, php-imap was retired, why wouldn't we obsolete it?
I misread the earlier output included here to indicate that nextcloud was depending on it. Please ignore my objections. Even rereading I'm not sure what that output is supposed to indicate.
this time on upgrade of my laptop instead run: dnf system-upgrade --releasever=34 --skip-broken -y ( not upgrading to Fedora 35 is to Fedora 34 ) I ran : dnf system-upgrade download --refresh --releasever=34 --allowerasing -y and the packages in question was correctly removed [1], but just works when it is added --allowerasing , I don't know if it the most correct ... [1] Nov 06 00:44:30 ideapad.local dnf[1153]: Removed: Nov 06 00:44:30 ideapad.local dnf[1153]: ekiga-4.0.1-50.fc33.x86_64 Nov 06 00:44:30 ideapad.local dnf[1153]: kmod-nvidia-5.13.16-100.fc33.x86_64-3:495.44-1.fc33.x86_64 Nov 06 00:44:30 ideapad.local dnf[1153]: kmod-nvidia-5.14.14-100.fc33.x86_64-3:495.44-1.fc33.x86_64 Nov 06 00:44:30 ideapad.local dnf[1153]: kmod-nvidia-5.14.15-100.fc33.x86_64-3:495.44-1.fc33.x86_64 Nov 06 00:44:30 ideapad.local dnf[1153]: php-imap-7.4.25-1.fc33.x86_64 Nov 06 00:44:30 ideapad.local dnf[1153]: rdma-core-35.0-1.fc33.i686 Nov 06 00:44:30 ideapad.local dnf[1153]: Complete!