Description of problem: Once you modify your system repos using DNF5, their states are no longer synchronized with PackageKit. This is because DNF5 now doesn't modify repo files directly, but instead uses /etc/dnf/repos.override.d/ to store any changes performed to the repo. However, PackageKit still doesn't use libdnf5, and uses old libdnf (dnf4), which means it doesn't understand the override directory. It reads the repos directly, and modifies them directly too. This means that any DNF5-induced changes to repos are invisible to PackageKit. Also, any changes performed in PackageKit, which are also already included in the override config, are invisible to DNF5. For example, let's look at enabling or disabling the updates-testing repo. After a fresh installation of Fedora 42 pre-release, the configs look the same: $ sudo dnf repolist repo id repo name fedora Fedora 42 - x86_64 fedora-cisco-openh264 Fedora 42 openh264 (From Cisco) - x86_64 updates Fedora 42 - x86_64 - Updates updates-testing Fedora 42 - x86_64 - Test Updates $ pkcon repo-list | sort | grep Enabled Enabled fedora-cisco-openh264 Fedora 42 openh264 (From Cisco) - x86_64 Enabled fedora Fedora 42 - x86_64 Enabled updates Fedora 42 - x86_64 - Updates Enabled updates-testing Fedora 42 - x86_64 - Test Updates If we use DNF5 to disable updates-testing, it will create an override config, and the changes will not be visible to PackageKit: $ sudo dnf config-manager setopt updates-testing.enabled=0 $ sudo dnf repolist repo id repo name fedora Fedora 42 - x86_64 fedora-cisco-openh264 Fedora 42 openh264 (From Cisco) - x86_64 updates Fedora 42 - x86_64 - Updates $ pkcon repo-list | sort | grep Enabled Enabled fedora-cisco-openh264 Fedora 42 openh264 (From Cisco) - x86_64 Enabled fedora Fedora 42 - x86_64 Enabled updates Fedora 42 - x86_64 - Updates Enabled updates-testing Fedora 42 - x86_64 - Test Updates We need to repeat the same action for PackageKit manually: $ pkcon repo-disable updates-testing $ pkcon repo-list | sort | grep Enabled Enabled fedora-cisco-openh264 Fedora 42 openh264 (From Cisco) - x86_64 Enabled fedora Fedora 42 - x86_64 Enabled updates Fedora 42 - x86_64 - Updates If we now want to enable updates-testing again, doing it in PackageKit will only affect PackageKit, because the override config will still make it disabled for DNF5: $ pkcon repo-enable updates-testing $ pkcon repo-list | sort | grep Enabled Enabled fedora-cisco-openh264 Fedora 42 openh264 (From Cisco) - x86_64 Enabled fedora Fedora 42 - x86_64 Enabled updates Fedora 42 - x86_64 - Updates Enabled updates-testing Fedora 42 - x86_64 - Test Updates $ sudo dnf repolist repo id repo name fedora Fedora 42 - x86_64 fedora-cisco-openh264 Fedora 42 openh264 (From Cisco) - x86_64 updates Fedora 42 - x86_64 - Updates The same action needs to be repeated for DNF5: $ sudo dnf config-manager setopt updates-testing.enabled=1 $ sudo dnf repolist repo id repo name fedora Fedora 42 - x86_64 fedora-cisco-openh264 Fedora 42 openh264 (From Cisco) - x86_64 updates Fedora 42 - x86_64 - Updates updates-testing Fedora 42 - x86_64 - Test Updates This is how the override config now looks like: $ cat /etc/dnf/repos.override.d/99-config_manager.repo # Generated by dnf5 config-manager. # Do not modify this file manually, use dnf5 config-manager instead. [updates-testing] enabled=1 This is a clear regression over DNF4-enabled systems. In the current situation, it might easily happen that an administrator disables a repo through DNF5 and expects it to be disabled, but users will still continue to be able to use that repo through PackageKit (GNOME Software, KDE Discover, command-not-found integration, pkcon, etc). Similarly, a user might disable repo graphically e.g. in GNOME Software, only to be later surprised by a DNF command ignoring that action. Version-Release number of selected component (if applicable): dnf5-5.2.12.0-1.fc42.x86_64 PackageKit-1.2.8-9.fc42.x86_64 How reproducible: always Steps to Reproduce: 1. sudo dnf config-manager setopt reponame.enabled=0 2. see that "reponame" is still enabled in `pkcon repo-list`
Sure, this sounds like a bug -- but the fix needs to come from the dnf team -- it must be their responsibility to patch up key users of the [binary] API when the [behavioural] API changes. There's a team of people writing dnf now, and PackageKit is very lightly maintained downstream now -- I don't think I'm really supposed to be working on it.
Thanks for your response, Richard. I'll propose this for a blocker discussion. Let's see if this is deemed to match our release criteria. In particular this one: ~~~~ The default graphical package manager for a given software type must appropriately: * Configure software sources by enabling/disabling pre-defined official repositories and then adjust the available software pool accordingly ... The displayed state of software or software sources must not differ from their actual state. (E.g. an RPM package must not be shown as installed when it is not, a repository must not be shown as disabled or missing when it is enabled, etc). ~~~ https://fedoraproject.org/wiki/Fedora_42_Final_Release_Criteria#Installing,_removing_and_updating_software
+5 in https://pagure.io/fedora-qa/blocker-review/issue/1812 , marking accepted blocker. We can discuss strategies for addressing this at blocker and/or go/no-go meetings.
Let's re-assign this to libdnf to get the developers' opinion on what needs to happen here, per Richard's comment above.
Frankly this won't go anywhere in time frame of releasing Fedora 42. If GUI users keep using GUI, they will be fine.
In the long term GUI is supposed to move to libdnf5.
Thanks for the update, Petr. I expected that we're unlikely to fix this in F42. > If GUI users keep using GUI, they will be fine. There are different wrinkles and corner cases, like admins probably configuring the system using dnf, and then non-admin GUI users being allowed to install software from configured repositories, which might however not match the admin expectations. Even for a single-user system, this might be very confusing, if you're not aware of the problem. I'll try to document this problem using CommonBugs.
Petr, what did you mean to change the bug title to? It seems to be missing a word. "libdnf (DNF4) should edit DNF5 repo configuration using [what?] because of repo overrides"...
(In reply to Adam Williamson from comment #8) > Petr, what did you mean to change the bug title to? It seems to be missing a > word. "libdnf (DNF4) should edit DNF5 repo configuration using [what?] > because of repo overrides"... Thanks for the check. I corrected the title.
Discussed at 2025-04-10 F42 go/no-go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2025-04-10/fedora-linux-final-go-no-go-meeting.2025-04-10-17.01.html . We agreed that the blocker status for this bug remains, but it is waived to Fedora 43 Beta per the https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases "Difficult to fix blocker bugs" category: the planned fix for this is to port GNOME Software (and later, I guess, Discover?) to libdnf5, but that is not yet completed, and it wouldn't be appropriate to land such a large change in F42 at the last minute anyway. So for F42 we will have to live with this, and document it.
Common Issues description: https://discussion.fedoraproject.org/t/common-issue/148704
So, the port of gnome-software to libdnf5 is in progress and should land in Rawhide soon, but what about other package managers? KDE uses Discover, which is also based on PackageKit, AIUI. Is there a plan to port Discover to libdnf5? If not, is anyone planning to port PackageKit to libdnf5? If not, what do we do? CCing Neal for that angle. Beyond that, dnfdragora is used on a lot of other spins...it's not release blocking, but I guess it'd be good to know if it's affected by this at all. I would like there to be a clear plan for how this is expected to be 'addressed' for Fedora 43 Beta.
Jarek Rohel is trying to implement reading DNF5 configuration overrides in libdnf <https://github.com/rpm-software-management/libdnf/pull/1704>. However, DNF team cannot port all libdnf users to libdnf5. You need to direct your question to them: rdieter, rhughes, ngompa. As far as I know nobody wants to maintain PackageKit and they are rather going to move to libdnf5 directly. At least that was the plan for Gnome Software <https://fedoraproject.org/wiki/Changes/SwitchToDnf5#GNOME_Software_support>. I also saw a similar activity on dnfdragora side <https://github.com/manatools/dnfdragora/issues/214>. 2.99.0 <https://github.com/manatools/dnfdragora/releases/tag/2.99.0> is already in Fedora 43.
(In reply to Petr Pisar from comment #13) > Jarek Rohel is trying to implement reading DNF5 configuration overrides in > libdnf <https://github.com/rpm-software-management/libdnf/pull/1704>. > > However, DNF team cannot port all libdnf users to libdnf5. You need to > direct your question to them: rdieter, rhughes, ngompa. > > As far as I know nobody wants to maintain PackageKit and they are rather > going to move to libdnf5 directly. At least that was the plan for Gnome > Software > <https://fedoraproject.org/wiki/Changes/SwitchToDnf5#GNOME_Software_support>. I maintain PackageKit upstream with Matthias Klumpp. However, I've been asking for API tutorials and documentation for the C++ API to port PackageKit for about a year now. > I also saw a similar activity on dnfdragora side > <https://github.com/manatools/dnfdragora/issues/214>. 2.99.0 > <https://github.com/manatools/dnfdragora/releases/tag/2.99.0> is already in > Fedora 43. dnfdragora has never used PackageKit. The original dnfdaemon is maintained by the ManaTools group, and dnfdragora is slowly moving to the dnf5daemon implementation.
I tried to implement reading and writing libdnf5 configuration in libdnf - PR https://github.com/rpm-software-management/libdnf/pull/1704 . - The reads are including system and distribution drop-in directories and system and distribution repository overrides. - libdnf supports writing repository configurations. Previously, the original repo files were overwritten. After applying PR, changes are written to "/etc/dnf/repos.override.d/99-config_manager.repo", as dnf5 config-manager does. - PR also tries to deal with installroot I have partially tested PR. PR aims to improve the current situation, but it is definitely not the final solution. Even if the old libdnf will be "configuration compatible" with dnf5 it still uses a different software database. Mixing dnf5 and tools using the old libdnf will result in two out of sync software databases on the system, thus breaking transaction history and package installation reasons. If we want to continue using PackageKit, the best solution is to create a new libdnf5 backend for it.