Bug 2354865

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.

What is the status of this ahead of F43 Beta? As this was waived from F42 Final it automatically became an F43 Beta blocker. It would be good to know where it stands currently.

The fix has been merged upstream after 0.74.0 release. Upstream needs to do a release and Fedora needs to rebase to it.

I've implemented support for reading and writing libdnf5 configuration within libdnf in PR https://github.com/rpm-software-management/libdnf/pull/1704.

This also requires PR https://github.com/rpm-software-management/libdnf/pull/1710, which includes fixes and an extension for improved compatibility with libdnf5.

These PRs have been merged into upstream. But as Petr Písař noted, they aren't in a release yet.

There still has been no new release of libdnf, and the Fedora 43 Beta freeze is fast approaching. Can we please either cut a new release or backport the necessary fixes for this bug? Thanks.

Sorry we didn't cut a release before the Beta freeze. We're planning to make a new release of dnf and libdnf during the freeze.

That feels unfortunate :/ The earlier you can do it, the better.

Hi Evan, how are we standing up with this? Go/NoGo is this Thursday, we need to create an RC today or tomorrow.

FEDORA-2025-5cc2c62c29 (libdnf-0.74.0-6.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-5cc2c62c29

To at least *try* and have something for go/no-go, I went ahead and backported the PRs mentioned above. It didn't *look* like new builds of dnf or dnf5 were required, so I didn't do any. If I got it wrong, we don't lose anything much. Please test this in the Beta candidate when it lands.

It seems to work fine. I tested repo changes by dnf, by pkcon, and by gnome-software. All of them modify the override file correctly, the resulting state is displayed correctly in all of them.

dnf5-5.2.17.0-1.fc43.x86_64
PackageKit-1.2.8-13.fc43.x86_64

Thanks, Adam. It's taken us longer than expected to get our tests passing to make an upstream release, after a while of only worrying about DNF4 in RHEL. The backport looks good to me.

FEDORA-2025-5cc2c62c29 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-5cc2c62c29`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-5cc2c62c29

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

I reviewed the Fedora patches and the ABI difference and built this change also for Fedora 44.

FEDORA-2025-5cc2c62c29 (libdnf-0.74.0-6.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.