Dnf update stalled by conflict

Error: Transaction test error:
  file /usr/share/doc/at-spi2-core/NEWS from install of at-spi2-core-
2.48.2-1.fc38.i686 conflicts with file from package at-spi2-core-
2.48.0-1.fc38.x86_64
  file /usr/share/doc/libssh/CHANGELOG from install of libssh-0.10.5-
1.fc38.i686 conflicts with file from package libssh-0.10.4-
4.fc38.x86_64

Welcome to the Fedora Project @davec

This is a Architecture conflict. You have to remove the .i686 before let the .x86_64 app install. This happens sometimes while using Wine/other apps, who still use 32 Bit apps.

1 Like

I’m a linux newbie. How do I remove the i686?

Please get first a bit informed how to make a useful topic that we can understand what you are trying to do and what your troubles are.

For this I propose you to read/scan the pinned articles first.

Ask Fedora | start-here

If you know how to ask more precise, we will be able to give you more precise answer :fedora:

RPM (the packaging system underying DNF) has “magic” which allows the 32-bit “i686” and 64-bit “x86_64” versions of the same package to be installed at the same time — but this magic only works when both are the exact same version.

As you can see if you look carefully at the numbers, the release numbers of the at-spi2-core and libssh packages don’t match. This problem often happens when you’re trying to just update some subset of things, and DNF gets a little confused. It can also happen when mirrors are out of sync.

In the first case, if you do a general “dnf upgrade” to get everything to the latest, that should work. Or, if it’s the second, it should resolve itself after a few hours or maybe days.

In the meantime, using dnf upgrade --skip-broken should skip these packages until the problem is resolved. Or, as @ilikelinux has noted, you can just remove the i686 packages — in this case, that’d be:

sudo dnf remove at-spi2-core.i686 libssh.i686

This will almost certainly prompt you to remove a bunch of other i686 packages. That’s probably okay and in most cases you don’t really need them. However, if you have Steam installed via RPM, that might be one of the “casualties”.[1]

Once you’ve removed the i686 packages, you should have no conflicts — and after updating, you should be able to dnf install them again, if you want to for some particular reason.


  1. Personally, I recommend installing Steam from the Flatpak, which avoids the problem. ↩︎

I tested this but it wanted to remove also gnome shell stuff … so update might be better.

The i686 gnome shell stuff shouldn’t be necessary. I agree that it’s a little scary, though!

I tested so:

sudo dnf remove at-spi2-core as i do not have .i686 installed. And the message was:

Error: 
 Problem: The operation would result in removing the following protected packages: gnome-shell
(try to add '--skip-broken' to skip uninstallable packages)

If a newbie does the same attempt as I and even uses --skip-broken it will be done more harm then help.

Oh — and this is going a little off topic, so I’ll start a new topic if we have a lot more to say on it! — that’s a bug in DNF’s “package protection” feature. It really shouldn’t give that warning if you’re just removing the i686 gnome shell packages and leaving the x86_64 ones (which you are, in this case). But you’re right, because of that, removing the package might not work.

You can bypass dependency check like this:

sudo rpm --nodeps -e at-spi2-core.i686
sudo rpm --nodeps -e libssh.i686
1 Like

I get concerned that using rpm like this will have dnf complain the the rpm database is out of sync won’t it?

And that would leave the system in potentially a worse situation?

Both rpm and dnf operate on the same database, so it cannot become out of sync.
If necessary, you can reinstall those packages after upgrading.

Dnf tracks more things than rpm, and at some point in the past, yum (and maybe early dnf?) would complain about direct rpm operations breaking the history. It doesn’t anymore, though.

Removing packages with --nodeps can leave the system in a messy state. In this case it’s unlikely to cause a real problem — but it’s good to be cautious.

The DNF history is stored separately and even removing it completely cannot damage the RPM database integrity, so there’s barely any need to care about a couple of missing records.
It should work fine for this issue since no essential packages are involved.