Bug 1044999 - [doc] show dependencies during update
Summary: [doc] show dependencies during update
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 20
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Ales Kozumplik
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-12-19 12:19 UTC by Kamil Páral
Modified: 2018-02-19 15:50 UTC (History)
12 users (show)

Fixed In Version: dnf-0.4.10-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-01-04 19:53:41 UTC
Type: Bug

Attachments (Terms of Use)

Description Kamil Páral 2013-12-19 12:19:38 UTC
Description of problem:
I wanted to update my system and some new packages are marked to be installed. But I don't see any reason why. Is it a new dependency of some existing package? Is it a new required package in some existing package group? Please make the output indicate that somehow.

See protobuf-c in:

Version-Release number of selected component (if applicable):

Comment 1 Ales Kozumplik 2013-12-19 12:42:08 UTC
Hi Kamil, DNF does not yet support groups as objects so it does not check whether the comps have changed and new packages will be installed. When we decide to support it we can add this output.

As for changed dependencies of an existing package: we don't know concrete reasons why a resolving ended with particular results and that's a good thing. We only guarantee the user that the result is optimal (from libsolv's point of view) and that we don't introduce any inconsistencies into the RPMDB. There's nothing we are going to do more in this area.

Not sure what to do with the bug now: it asks for a feature of something that does not exist. Do you want to open a bug for groups as objects or can I close this?

Comment 2 Zdeněk Pavlas 2013-12-19 12:44:48 UTC
---> Package protobuf-c.x86_64 0.15-8.fc20 will be installed
---> Package protobuf-compiler.x86_64 2.5.0-5.fc20 will be installed
All the others are just updates.

It's probably just a dependency of some updated package. run: "rpm -q --whatrequires protobuf-c" to find what pulled this in.

Comment 3 Kamil Páral 2013-12-19 13:12:08 UTC
> we don't know concrete reasons why a resolving ended with particular results

Oh, interesting. But a bit unfortunate, from user POV. Yum tells me something like this:

---> Package libgadu.x86_64 0:1.12.0-0.2.rc1.fc20 will be an update
--> Processing Dependency: libprotobuf-c.so.0()(64bit) for package: libgadu-1.12.0-0.2.rc1.fc20.x86_64

In this example, it's very simple. But sometimes I see a large number of dependencies added and an output like the above really helps. Sometimes I discover that a completely useless package caused it and I rather remove it (prior to upgrade) than to download and install lots of its dependencies.

Hm, hm, would it be possible to do something like this?
If there are new packages installed during upgrade, compare their requirements with provisions of the to-be-upgraded set of packages and print a similar output:
---> Package protobuf-c.x86_64 0.15-8.fc20 will be installed
-----> A dependency of: libgadu-1.12.0-0.2.rc1.fc20

But hey, maybe I don't need this, maybe I'll get used to the missing information. I was simply used to see it with yum. I reported this bug because I believed it was simply an omission inside dnf.

If you decide not to implement this, just close this (and keep in mind this could be useful for package group updates).

Comment 4 Ales Kozumplik 2013-12-19 13:20:16 UTC
Yum shows these 'Processing Dependency' lines but they do more confusion than good. I'll document this properly so people know we don't do it on purpose.

Comment 5 Ales Kozumplik 2013-12-19 13:40:51 UTC
Documented in cc438a3, will be included in dnf-0.4.10.

Comment 6 Fedora Update System 2014-01-02 10:10:43 UTC
dnf-0.4.10-1.fc20 has been submitted as an update for Fedora 20.

Comment 7 Fedora Update System 2014-01-03 08:42:07 UTC
Package dnf-0.4.10-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dnf-0.4.10-1.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 8 Fedora Update System 2014-01-04 19:53:41 UTC
dnf-0.4.10-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 9 Ben Boeckel 2014-01-08 15:55:10 UTC
Would it be possible to get verbose output to see these? My use case: installing a bunch of -devel packages for some project and trimming out those which are dragging in too much (maybe it chains off into KDE-land, Java-land or something). Without the output, tracking down the cause of some huge dependency chain would get much harder. I also file bugs about over-broad Requires which this helps with.

Hmm...<musing ignorability="high">Maybe dumping out DOT files for a transaction would be useful (edge colors being the action/reasoning).</musing>

Comment 10 Artem S. Tashkinov 2014-06-26 12:19:08 UTC
(In reply to Ales Kozumplik from comment #4)

Says who?

What if I want to parse DNF output?

What if I want to understand what additional dependencies a certain updated package brings?

Please, show this information or at least give an option to show it.

Comment 11 Artem S. Tashkinov 2014-06-26 12:20:36 UTC
I request this bug to be reopened.

Dumbing down every app just because you get confused by several additional lines of output is not an excuse for removing crucial information.

Comment 12 Valdis Kletnieks 2015-05-29 21:41:18 UTC
(In reply to Artem S. Tashkinov from comment #11)
> I request this bug to be reopened.
> Dumbing down every app just because you get confused by several additional
> lines of output is not an excuse for removing crucial information.

Seconding this.

I'm currently sitting here on Fedora Rawhide, and 'dnf list updates'
shows 'wireshark'.  Saying 'dnf update wireshark' says "nothing to do".

At leas if you did 'yum update wireshark', it would go down the list of updates, pre-req updates, and finally blow up and say (verbosely) "sorry, no can do, because wireshark wants libfoo-0.17, but moby-wooble still needs libfoo-0.16".

I can find no way to get the equivalent reason of *why* the dnf update solver thinks there's nothing to do for 'update wireshark'.  As several others have pointed out, often the problem is some obscure 3rd party RPM linked against an older library, and removing the un-needed RPM allows the update to complete (I'm looking at *you*, rpmfusion :)

Comment 14 Radek Holy 2015-06-01 07:56:30 UTC
Also note that there is this RFE: bug 1210445. It will at least print the "wireshark" part. The "libfoo" part is another story.

Comment 15 stan 2016-05-13 13:34:32 UTC
I know this is old and closed, but I found it while searching for a solution to the problem it addresses.

I agree with comment 12.  I'm sitting here in rawhide for F25, and when I do a dnf upgrade, 366 packages are skipped.  But I have no way of knowing *why* they were skipped.  If I want to open a ticket to get an update to a dependent package, I have no idea which package I should open it against.

I try dnf update --best, and get a list of 30 dependencies that are not met, so still haven't a concrete idea of which package needs to be updated to satisfy dependencies.  It's like a logjam, and I want to know the one log that is holding back the whole jam.

Maybe there should be a new program, say 'why-dnf-dependencies-fail-for' that can be run on a package, and spit out the package that is causing the dependency failure.  Or maybe it already exists under another name.

There, I feel better after my rant.  :-)

Note You need to log in before you can comment on or make changes to this bug.