5

I recently tried to update some packages on my (fedora 27, x64) machine, which dnf complains is in conflict. However, I cannot figure out how to get dnf to tell me the cause of the conflict.This related question says that I should use --best to solve the problem, but this still doesn't tell me why a seemingly non-conflicting situation is considered a conflict.

The TL;DR of this question is: how do I get dnf to tell me which packages are conflicting and what the associated dependents are?

The following is the conflict:

$dnf update Last metadata expiration check: 1:49:45 ago on Tue 27 Nov 2018 03:16:34 PM CET. Dependencies resolved. Problem: problem with installed package i3status-2.12-1.fc27.x86_64 - package i3status-2.12-1.fc27.x86_64 requires libconfuse.so.1()(64bit), but none of the providers can be installed - cannot install both libconfuse-3.2.2-1.fc27.x86_64 and libconfuse-3.2-3.fc27.x86_64 - cannot install both libconfuse-3.2-3.fc27.x86_64 and libconfuse-3.2.2-1.fc27.x86_64 - cannot install the best update candidate for package libconfuse-3.2-3.fc27.x86_64

I figured out (with dnf --deplist info) that i3status-2.12-1.fc27.x86_64 depends on libconfuse-3.2-3.fc27.x86_64:

 dependency: libconfuse.so.1()(64bit) provider: libconfuse-3.2-3.fc27.x86_64

However, I cannot for the life of me figure out what thing depends on the older libconfuse-3.2.2-1.fc27.x86_64 package. I assumed reverse dependencies of installed packages would be easy to search, but the solution suggested here states that dnf repoquery --available --alldeps --source --whatrequires libconfuse-3.2.2-1.fc27.x86_64 should do the trick; however the output is:

Last metadata expiration check: 1:59:58 ago on Tue 27 Nov 2018 03:16:34 PM CET. libconfuse-3.2.2-1.fc27.src.rpm

And of that rpm, there are no dependencies at all. In other words, the only package that requires this is the package itself, but this doesn't happen all the time, so I'm guessing this list is somehow incomplete. Digging into dnf repoquery a bit, I found that dnf repoquery --all --installed --whatrequires libconfuse should give me the desired output. This says:

i3status-0:2.12-1.fc27.x86_64

Which is the package that was originally listed as the package I want to update, yet as already pointed out above, this depends on libconfuse.so.1()(64bit) provided by libconfuse-3.2-3.fc27.x86_64. In other words, there should be no conflict, according to this output. What am I missing here?

Improve this question
3
  • 1
    You probably need to file a bug report, however fedora 27 is almost at EOL so perhaps best to upgrade to 28 or 29 Commented Nov 27, 2018 at 17:54
  • @Panther I thought an update would have similar issues, so I figured it best to fix this and upgrade afterwards. In general, to whom should I file the bug report in a case like this? I don't feel that I understand whether the cause is a bug in dnf, an error in the i3status package dependencies, in the libconfuse package specification, or in my understanding of how dnf handles dependencies (I assumed the last of these was the issue). Commented Nov 28, 2018 at 6:29
  • 1
    Libconfuse I would think. They will close it when 27 goes eol in a few days so file it fast .... 3 or 4 days max Commented Nov 28, 2018 at 7:21

2 Answers 2

Reset to default
3

The following command will return a list of the installed packages that depend on libconfuse and the exact version and architecture they depend on:

sudo dnf repoquery --whatdepends libconfuse \ --queryformat "%{name}.%{arch} %{version}-%{release}" 2>/dev/null \ | grep -F -f <(sudo dnf list installed \ | tr -s '[[:space:]]' | cut -d ' ' -f-2) \ | xargs -L1 sudo dnf repoquery --deplist 2>/dev/null \ | grep 'package\|libconfuse'

(Make sure to replace both appearances of libconfuse with the library name dnf has the conflict with without any version number, otherwise it won't work)

Improve this answer
0

This script would need to be ran as root/sudo.

#!/bin/bash dnf repoquery --whatdepends "${1} \ --queryformat "%{name}-%{version}-%{release}.%{arch} 2>/dev/null \ | xargs -I '{}' bash -c 'rpm -q {} &>/dev/null && echo {}'

A pure dnf solution could be done by replacing rpm -q {} with dnf list installed {}, but this increases the runtime MASSIVELY. While this can be slightly mitigating by building a cache (dnf makecache) initially and telling all dnf commands to use this cache (dnf -C), it is still far slower then querying rpm directly.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.