Conflicts with libdnf5, dnf5, dnf-data and kio-extras when trying to upgrade from Fedora 40 to Fedora 41

Running on freshly updated (as of today) Fedora 40
sudo dnf5 --no-best --releasever 41 system-upgrade download
ends with the following error:

Transaction failed: Rpm transaction failed.
  - file /etc/dnf/dnf.conf from install of libdnf5-5.2.6.2-1.fc41.x86_64 conflicts with file from package dnf-data-4.21.1-1.fc40.noarch
  - file /usr/lib64/qt6/plugins/kf6/kio/info.so from install of kio-extras-info-24.08.0-1.fc41.x86_64 conflicts with file from package kio-extras-24.08.0-1.fc40.x86_64
  - file /usr/share/man/man5/dnf.conf.5.gz from install of dnf5-5.2.6.2-1.fc41.x86_64 conflicts with file from package dnf-data-4.21.1-1.fc40.noarch

How to fix this?

Remove the --no-best and add --allowerasing

dnf5 on F41 comes with an empty etc/dnf/dnf.conf, it tries to overwrite your existing with a blank one.
You better rename it and let create dnf the new blank one. So you still have a copy.

On fedora f41 the system default seams to be defined in:

cat /usr/share/dnf5/libdnf.conf.d/20-fedora-defaults.conf
[main]
best=False
skip_if_unavailable=True

/etc/dnf/dnf.conf is provided by libdnf5 as a config file marked with noreplace, so the new incomming file will be /etc/dnf/dnf.conf.rpmnew.

%files -n libdnf5 -f libdnf5.lang
%if %{with dnf5_obsoletes_dnf}
%config(noreplace) %{_sysconfdir}/dnf/dnf.conf
%dir %{_sysconfdir}/dnf/vars
%dir %{_sysconfdir}/dnf/protected.d
%else
%exclude %{_sysconfdir}/dnf/dnf.conf
%endif

The condition dnf5_obsoletes_dnf is set for f41 and unset for f40 and earlier.

Thanks @vekruse for clarifications. That seams to be correct what you say. It is just so, that the OP has still dnf4 in use and the package who is interfering seams to be dnf-data-4.21.1-1.

Bringing up dnf5 on the level of F41 before upgrading would probably solve such kind of issues?
An other issue is that the sim-link is changing from dnf5 to dnf while on F40 the sim-link still is pointing to dnf4.

I am in a similar situation as the OP using dnf5 since it was announced that we will move to it. Now we get punished with such errors (or blessed, I do not know it exactly :slight_smile: ).

In my case I just deleted the sim-link while being on F40 and created the link dnf pointing to dnf5.
Testing the OP’s strings brings no errors till the upgrades overview (y/n question). After confirm with yes i got some errors:

Errorlist relaying on dnf
 Problem 12: cannot install both python3-libs-3.12.6-1.fc40.x86_64 and python3-libs-3.13.0~rc2-3.fc41.x86_64
  - package python3-3.12.6-1.fc40.x86_64 requires python3-libs(x86-64) = 3.12.6-1.fc40, but none of the providers can be installed
  - package python3-libdnf-0.73.3-1.fc41.x86_64 requires libpython3.13.so.1.0()(64bit), but none of the providers can be installed
  - package proton-vpn-gtk-app-4.5.0-1.fc40.noarch requires python(abi) = 3.12, but none of the providers can be installed
  - cannot install the best update candidate for package python3-libdnf-0.73.3-1.fc40.x86_64
  - cannot install the best update candidate for package proton-vpn-gtk-app-4.5.0-1.fc40.noarch
 Problem 13: package python3-3.12.6-1.fc40.x86_64 requires python3-libs(x86-64) = 3.12.6-1.fc40, but none of the providers can be installed
  - cannot install both python3-libs-3.12.6-1.fc40.x86_64 and python3-libs-3.13.0~rc2-3.fc41.x86_64
  - package python3-proton-core-0.3.3-1.fc40.noarch requires python(abi) = 3.12, but none of the providers can be installed
  - package python3-libdnf5-5.2.6.2-1.fc41.x86_64 requires libpython3.13.so.1.0()(64bit), but none of the providers can be installed
  - cannot install the best update candidate for package python3-proton-core-0.3.3-1.fc40.noarch
  - cannot install the best update candidate for package python3-libdnf5-5.1.17-2.fc40.x86_64

The errors are not relaying on dnf4 I have, they are because I do have a proton package installed where is not default fedora. I will have to deactivate the repository to do a eventual upgrade. I will probably not upgrade this machine I made the test with, because I like to clean it up and use F41 stable then.

Objective to report my thoughts here is to share unexpected errors while make an upgrade. In my case in point of view of an dnf5 user on F40 / F39.

That would be resolved if dnf-data and libdnf5 are both upgraded in the same transaction, which would normally be the case unless some other requirements prevent one of the packages to be upgraded.

1 Like

In my case I just deleted the sim-link while being on F40 and created the link dnf pointing to dnf5.

Can you please explain this in more detail? I am stuck in a similar situation.

This is from a system that has been fully upgraded from f40 to f41

# ls -l /usr/bin/dnf*
lrwxrwxrwx. 1 root root       4 Sep 19 19:00 /usr/bin/dnf -> dnf5
-rwxr-xr-x. 1 root root    1986 Aug 14 19:00 /usr/bin/dnf-3
lrwxrwxrwx. 1 root root       5 Aug 14 19:00 /usr/bin/dnf4 -> dnf-3
-rwxr-xr-x. 1 root root 1472592 Sep 19 19:00 /usr/bin/dnf5

and this is from an f40 system

$ ls -l /usr/bin/dnf*
lrwxrwxrwx. 1 root root    5 Aug 14 19:00 /usr/bin/dnf -> dnf-3
-rwxr-xr-x. 1 root root 1981 Aug 14 19:00 /usr/bin/dnf-3
lrwxrwxrwx. 1 root root    5 Aug 14 19:00 /usr/bin/dnf4 -> dnf-3

Note that dnf is a symlink to the binary that is actually used.
dnf3 is python based while dnf5 is c++ based.

If you have dnf5 installed and you wish to use dnf5 when using the dnf command you must ensure that the symlink points to the proper binary . The ln command is used to create a symlink and the man page tells how to do so.

You can use the ls command as I show above to find out what is happening. If dnf still is linked to dnf3 then either use the command dnf5 or remove the existing symlink and create a new one that now links to the dnf5 command.

I’m afraid dnf5 does not have --allowerasing option :frowning:

That would be resolved if dnf-data and libdnf5 are both upgraded in the same transaction, which would normally be the case unless some other requirements prevent one of the packages to be upgraded.

I guess sudo dnf5 --no-best --releasever 41 system-upgrade download makes it clear that both dnf-data and libdnf5 are indeed going to be upgraded in the same transaction yet the command ends with error about conflicts.

You guess. Check the list of packages to be downloaded and make sure.

file /etc/dnf/dnf.conf from install of libdnf5-5.2.6.2-1.fc41.x86_64 conflicts with file from package dnf-data-4.21.1-1.fc40.noarch

shows conflict between the fc40 version of dnf-data and the fc41 version of libdbf5.

By the way, why specifying --no-best?

Perhaps there is a bug when the version of dnf-data is 4.21.1 for both fc40 and fc41 and therefore dnf dicides that updating is not required.

It seems you are right and only libdnf5 package is on the list of packages to be installed (dnf-data is not present on the list):

[ 286/2942] libdnf5-0:5.2.6.2-1.fc41.x86_64                                                                                                               
>>> Already downloaded

Not using the option earlier resulted in many conflicts and suggestion to add this option. However I then removed some packages trying to minimize number of conflicts and now the output with and without --no-best is the same (shown in my question).

I could try it; how can I download version of libdnf5 package from Fedora 41 so that I could install it on Fedora 40?

Maybe you can downgrade dnf to the version found in https://koji.fedoraproject.org/koji/buildinfo?buildID=2481986

That would get the previous version of dnf-data and that would make sure that fc41 has a newer version than the installed version.

I do not have package dnf installed. If I remember well I removed it at some point.

$ dnf5 list --installed '*dnf*'
Installed packages
dnf-data.noarch                          4.21.1-1.fc40 updates
dnf5.x86_64                              5.1.17-2.fc40 updates
libdnf.x86_64                            0.73.3-1.fc40 updates
libdnf5.x86_64                           5.1.17-2.fc40 updates
libdnf5-cli.x86_64                       5.1.17-2.fc40 updates
python3-dnf.noarch                       4.21.1-1.fc40 updates
python3-dnf-plugins-extras-common.noarch 4.1.2-1.fc40  <unknown>
python3-libdnf.x86_64                    0.73.3-1.fc40 updates

Update to the above. I think the reason for --no-best having no effect was due to best=False set in /etc/dnf/dnf.conf. After removing it this is what I get:

$ sudo dnf5 --releasever 41 system-upgrade download
Updating and loading repositories:
Repositories loaded.
Failed to resolve the transaction:
Problem 1: package docker-cli-27.2.0-1.fc41.x86_64 conflicts with podman-docker provided by podman-docker-5:5.2.2-1.fc41.noarch
  - package docker-compose-2.29.2-1.fc41.x86_64 requires docker-cli, but none of the providers can be installed
  - cannot install the best update candidate for package podman-docker-5:5.2.2-1.fc40.noarch
  - cannot install the best update candidate for package docker-compose-1.29.2-12.fc40.noarch
 Problem 2: package docker-compose-2.29.2-1.fc41.x86_64 requires docker-cli, but none of the providers can be installed
  - package docker-cli-27.2.0-1.fc41.x86_64 conflicts with podman-docker provided by podman-docker-5:5.2.2-1.fc41.noarch
  - problem with installed package
  - problem with installed package
  - package docker-compose-1.29.2-12.fc40.noarch requires python(abi) = 3.12, but none of the providers can be installed
  - package podman-docker-5:5.2.2-1.fc40.noarch requires podman = 5:5.2.2-1.fc40, but none of the providers can be installed
  - cannot install both python3-3.12.6-1.fc40.x86_64 and python3-3.13.0~rc2-3.fc41.x86_64
  - cannot install both podman-5:5.2.2-1.fc40.x86_64 and podman-5:5.2.2-1.fc41.x86_64
  - cannot install the best update candidate for package python3-3.12.6-1.fc40.x86_64
  - cannot install the best update candidate for package podman-5:5.2.2-1.fc40.x86_64
You can try to add to command line:
  --no-best to not limit the transaction to the best candidates

This looks like a bug with the podman package.
I was able to update after removing podman-docker, updating and then doing sudo dnf install podman-docker --allowerasing

1 Like

dnf is not a package name! It is the command name.

search for dnf* to find the packages.
The packages are clearly named as dnf4 and dnf5.

This was more a rhetorical statement and I meant this would simply-fie the dnf5 upgrade process in general.

Must have a reason that we not made it this way.

But you have dnf-data installed, and I was suggesting to download that at least so you would have dnf-data-4.21.0-1.fc40.noarch.rpm installed instead of dnf-data-4.21.1-1.fc40.noarch.

Try it, and it will be clear that there is no package named dnf4 and there is a package named dnf

[root@newbox ~]# dnf list dnf\*
Last metadata expiration check: 0:14:13 ago on Tue 24 Sep 2024 06:37:57 CEST.
Installed Packages
dnf.noarch                                                          4.21.1-1.fc40                                         @updates
dnf-data.noarch                                                     4.21.1-1.fc40                                         @updates
dnf-plugins-core.noarch                                             4.9.0-1.fc40                                          @updates
dnf-utils.noarch                                                    4.9.0-1.fc40                                          @updates
dnf5.x86_64                                                         5.1.17-2.fc40                                         @updates
dnf5-plugins.x86_64                                                 5.1.17-2.fc40                                         @updates
Available Packages
dnf-automatic.noarch                                                4.21.1-1.fc40                                         updates 
dnf-plugin-diff.noarch                                              1.1-19.fc40                                           fedora  
dnf-plugin-ovl.noarch                                               0.0.3-14.fc40                                         fedora  
dnf-repo.x86_64                                                     0.6.1-1.fc40                                          updates 
dnf5-devel.x86_64                                                   5.1.17-2.fc40                                         updates 
dnf5-plugin-automatic.x86_64                                        5.1.17-2.fc40                                         updates 
dnf5daemon-client.x86_64                                            5.1.17-2.fc40                                         updates 
dnf5daemon-server.x86_64                                            5.1.17-2.fc40                                         updates 
dnfdaemon.noarch                                                    0.3.22-1.fc40                                         fedora  
dnfdaemon-selinux.noarch                                            0.3.22-1.fc40                                         fedora  
dnfdragora.noarch                                                   2.1.5-3.fc40                                          fedora  
dnfdragora-updater.noarch                                           2.1.5-3.fc40                                          fedora  
[root@newbox ~]# 
1 Like

I tried symlink of dnf to dnf5, and then perform system update, but still getting the same errors:


Transaction failed: Rpm transaction failed.
  - file /etc/dnf/dnf.conf from install of libdnf5-5.2.6.2-1.fc41.x86_64 conflicts with file from package dnf-data-4.21.1-1.fc40.noarch
  - file /usr/share/man/man5/dnf.conf.5.gz from install of dnf5-5.2.6.2-1.fc41.x86_64 conflicts with file from package dnf-data-4.21.1-1.fc40.noarch
  - file /usr/share/man/man8/dnf-download.8.gz from install of dnf5-5.2.6.2-1.fc41.x86_64 conflicts with file from package dnf-plugins-core-4.9.0-1.fc40.noarch
  - file /usr/share/man/man8/dnf-system-upgrade.8.gz from install of dnf5-5.2.6.2-1.fc41.x86_64 conflicts with file from package dnf-plugins-core-4.9.0-1.fc40.noarch
  - file /usr/share/man/man8/dnf-builddep.8.gz from install of dnf5-plugins-5.2.6.2-1.fc41.x86_64 conflicts with file from package dnf-plugins-core-4.9.0-1.fc40.noarch
  - file /usr/share/man/man8/dnf-changelog.8.gz from install of dnf5-plugins-5.2.6.2-1.fc41.x86_64 conflicts with file from package dnf-plugins-core-4.9.0-1.fc40.noarch
  - file /usr/share/man/man8/dnf-config-manager.8.gz from install of dnf5-plugins-5.2.6.2-1.fc41.x86_64 conflicts with file from package dnf-plugins-core-4.9.0-1.fc40.noarch
  - file /usr/share/man/man8/dnf-copr.8.gz from install of dnf5-plugins-5.2.6.2-1.fc41.x86_64 conflicts with file from package dnf-plugins-core-4.9.0-1.fc40.noarch
  - file /usr/share/man/man8/dnf-needs-restarting.8.gz from install of dnf5-plugins-5.2.6.2-1.fc41.x86_64 conflicts with file from package dnf-plugins-core-4.9.0-1.fc40.noarch
  - file /usr/share/man/man8/dnf-repoclosure.8.gz from install of dnf5-plugins-5.2.6.2-1.fc41.x86_64 conflicts with file from package dnf-plugins-core-4.9.0-1.fc40.noarch