Opening Gnome Software in F43 and removing cantarell-VF font(s) will break gnome. Upon next boot you will be greeted with a shell login. Reproducible: Always Steps to Reproduce: 1. Start Gnome Software 2. remove Cantarell fonts 3. reboot Actual Results: breaks Gnome Desktop Expected Results: inhibit removal of cantarell font - should be marked as hard dependency of Gnome
Created attachment 2108134 [details] shell after reboot
Proposed as a Blocker and Freeze Exception for 43-final by Fedora user augenauf using the blocker tracking app because: This breaks DE
Thanks for a bug report. The gnome-software has no way to set dependencies between the packages, the less to "do not uninstall this one, because it needs something else". When running DNF: # dnf remove abattis-cantarell-vf-fonts Failed to resolve the transaction: Problem: installed package fontconfig-2.17.0-3.fc43.x86_64 requires font(:lang=en), but none of the providers can be installed - installed package cairo-1.18.4-2.fc43.x86_64 requires libfontconfig.so.1()(64bit), but none of the providers can be installed - installed package default-fonts-core-sans-4.2-5.fc43.noarch requires abattis-cantarell-vf-fonts, but none of the providers can be installed - installed package gnome-shell-49.0-1.fc43.x86_64 requires libcairo.so.2()(64bit), but none of the providers can be installed - conflicting requests - problem with installed package but when running pkcon, which uses PackageKit: # pkcon remove abattis-cantarell-vf-fonts Resolving [=========================] Querying [=========================] Testing changes [=========================] Finished [ ] (0%) The following packages have to be removed: ImageMagick-1:7.1.1.47-3.fc43.x86_64 An X application for displaying and manipulating images ImageMagick-libs-1:7.1.1.47-3.fc43.x86_64 ImageMagick libraries to link with NetworkManager-openconnect-gnome-1.2.10-9.fc43.x86_64 NetworkManager VPN plugin for OpenConnect - GNOME files NetworkManager-openvpn-gnome-1:1.12.3-1.fc43.x86_64 NetworkManager VPN plugin for OpenVPN - GNOME files NetworkManager-ssh-1.4.1-3.fc43.x86_64 NetworkManager VPN plugin for SSH ... gdm-1:49.0.1-6.fc43.x86_64 The GNOME Display Manager ... gnome-session-49.0-1.fc43.x86_64 GNOME session manager ... gnome-shell-49.0-1.fc43.x86_64 Window management and application launching for GNOME ... yelp-2:49.0-1.fc43.x86_64 Help browser for the GNOME desktop yelp-libs-2:49.0-1.fc43.x86_64 Libraries for yelp zenity-4.1.99-1.fc43.x86_64 Display dialog boxes from shell scripts Proceed with changes? [N/y] The pkcon lists tons of packages, basically suggests to uninstall the whole GNOME and many other dependencies. I'm moving this to PacakgeKit, where the problem is.
*** Bug 2400573 has been marked as a duplicate of this bug. ***
User discussion: https://discussion.fedoraproject.org/t/166684 This is not just about fonts, as mentioned in bug 2400573, packagekit has a regression in F43 allowing to remove protected packages defined in /etc/dnf/protected.d/. In F42, it denied the operation: $ pkcon remove abattis-cantarell-vf-fonts ... Fatal error: Could not depsolve transaction; 1 problem detected: Problem: The operation would result in removing the following protected packages: gnome-shell In F43, it's happy to remove a hundred packages including protected packages.
Might it be some dnf4 change? PackageKit still uses dnf4 under the hood and the error you provided from f42 looks like a dnf(4) claim, rather than a PackageKit claim.
For the record, I tested KDE as well. PackageKit regression in ignoring protected packages of course affects it as well. But KDE Discover (the graphical package manager) seems to have additional safeguards for removing Plasma desktop-essential packages, so neither in F42 nor in F43, I was able to uninstall the KDE desktop by searching for and trying to uninstall core desktop packages, that was always denied. It might be possible through some dependency (as in the case of cantarell fonts), I didn't spend that much time on it to test that thoroughly. (In reply to Milan Crha from comment #6) > Might it be some dnf4 change? PackageKit still uses dnf4 under the hood and > the error you provided from f42 looks like a dnf(4) claim, rather than a > PackageKit claim. CC @ppisar @jrohel for guidance from the DNF team, thanks!
Please describe what package is expected to be protected from the removal.
(In reply to Petr Pisar from comment #8) > Please describe what package is expected to be protected from the removal. I assume everything listed in /etc/dnf/protected.d/. At least that's how packagekit in Fedora 42 seems to work. I don't know how exactly it is implemented, but we'd like to know what changed in Fedora 43 regarding packagekit's behavior in this area.
(In reply to Kamil Páral from comment #9) > (In reply to Petr Pisar from comment #8) > > Please describe what package is expected to be protected from the removal. > > I assume everything listed in /etc/dnf/protected.d/. I meant a concrete example. Like what Gnome package the reporter expects to be protected. > but we'd like to know what changed in Fedora 43 regarding > packagekit's behavior in this area. There was only a single major change and that was reading DNF5 configuration files by libdnf (bug #2354865).
This is a libdnf regression, as the backend code has not changed in PackageKit.
Well, I'm unable to remove any package in "pkcon remove" command. It claims for me that it the removal finished, but then asks "Do you want to allow installing of unsigned software?". If I answer yes, the question is repeated indefinitely. When I answer no, it prints "Fatal error: user declined interaction" and exits. Result is that no package gets removed. Regardless of it listing in /etc/dnf/protected.d/.
I after downgrading to libdnf to 0.74.0-5.fc43, pkcon started to reject removing protected packages (Problem: The operation would result in removing the following protected packages:...). (It still is unable to remove any package for me, but that probably a different bug.) I confirm this behavior change is triggered by upgrading libdnf from 0.74.0-5.fc43 to 0.74.0-6.fc43. It's the change introduced in bug #2354865. Thanks, Ajax, for unilaterally pushing that change to Fedora because it's Beta freeze. Jarek, please could look at it? You have implemented it upstream.
dnf4 program is not affected. It only happens to pkcon.
(In reply to Petr Pisar from comment #10) > I meant a concrete example. Like what Gnome package the reporter expects to > be protected. $ cat /etc/dnf/protected.d/fedora-workstation.conf NetworkManager gnome-shell gnome-shell is the one that should've stopped the problem in comment 0, but didn't.
> Thanks, Ajax, for unilaterally pushing that change to Fedora because it's Beta freeze. 2354865 was itself a blocker, so we needed a fix for it. The fact that fix introduced this bug is unfortunate, but sending a fix for that bug was the right thing to do.
Reproducible with latest upstream libdnf-0.75.0-0.20251001011608.0.74.0+29.g8eadf440.fc44.x86_64 build. (And pkcon does end in the infinite loop in Fedora 44.)
Maybe it would be a good idea to protect fontconfig so all the fedora spins are protected from this issue. The list is massive so I will limit it $ dnf repoquery --whatrequires=fontconfig |grep -e gtk3 -e gtk4 Updating and loading repositories: Repositories loaded. PackageKit-gtk3-module-0:1.3.1-6.fc43.i686 PackageKit-gtk3-module-0:1.3.1-6.fc43.x86_64 gtk3-0:3.24.51-1.fc43.i686 gtk3-0:3.24.51-1.fc43.x86_64 gtk4-0:4.20.2-1.fc43.i686 gtk4-0:4.20.2-1.fc43.x86_64 gtk4-devel-0:4.20.2-1.fc43.i686 gtk4-devel-0:4.20.2-1.fc43.x86_64 webkit2gtk4.1-0:2.50.0-2.fc43.i686 webkit2gtk4.1-0:2.50.0-2.fc43.x86_64 removal of abattis-cantarell-vf-fonts = fontconfig removal = gtk4/4 removal = goodbye any unprotected gtk* based DE
I have investigated the issue. And it's clear. Fedora has additionally started distributing the protected_packages configuration in the drop-in directory "/usr/share/dnf5/libdnf.conf.d/". This does not affect the older libdnf version 0.74.0 because it doesn't support configuration in drop-in directories. libdnf version 0.75.0 includes support for loading configuration from drop-in directories and also repository overrides. This largely solved the configuration compatibility problem with libdnf5. However, in libdnf5, protected_packages is an append option. Therefore, adding additional protected packages via drop-in directories works correctly (they are appended). In libdnf, it is a regular option which is overwritten by the configuration in the drop-in directory. Thus, instead of merging all protected packages, the list contains only what was defined in the last loaded file. In my test, that was "/usr/share/dnf5/libdnf.conf.d/protect-setup.conf". A solution I have in mind is to change the protected_packages option in the libdnf to an 'append' type, just like it is in libdnf5. I also suggest performing a review to see if there are more such options that were changed to append in libdnf5.
Protected packages though, are a double edged sword beyond basic boot critical functionality. Someone might group install plasma, and then decide they want to remove it and continue using gnome. It seems to me that the protected packages stuff should be less granular. Protected to assure its possible to boot to a command line, and protected to assure a particular package group remains functional. Then individual groups can be removed without having to manually move/remove the protection files.
That's rather outside the scope of this bug, though.
AGREED AcceptedFinalFreezeException AcceptedFinalBlocker Discussed at the 2025-10-06 (blocker / freeze exception) review meeting: This is accepted on the proviso that we also amend the FInal criterion as proposed by kparal in https://pagure.io/fedora-qa/blocker-review/issue/1952#comment-988437 . this will be accepted as a violation of that amended criterion, but it is also accepted as a Freeze Exception to ensure it gets fixed for release even if it's not a blocker. https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2025-10-06/f43-blocker-review.2025-10-06-16.00.txt
The release criterion change is now proposed here: https://discussion.fedoraproject.org/t/release-criteria-change-proposal-honor-protected-packages-in-gui-package-managers/167616 Jaroslav, Petr, Milan - we appreciate your feedback as DNF and gnome-software developers. Thanks.
A fix was merged upstream. I will backport it to Fedora ≥ 43.
FEDORA-2025-005db2cfbf (libdnf-0.74.0-10.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-005db2cfbf
FEDORA-2025-005db2cfbf has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-005db2cfbf` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-005db2cfbf See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Fedora Update System from comment #25) > FEDORA-2025-005db2cfbf (libdnf-0.74.0-10.fc43) has been submitted as an > update to Fedora 43. > https://bodhi.fedoraproject.org/updates/FEDORA-2025-005db2cfbf This fixes the problem, protected packages can't be removed with packagekit/gnome-software.
FEDORA-2025-005db2cfbf (libdnf-0.74.0-10.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.