Bug 1227924
Summary: | "dnf upgrade" does not upgrade all the packages listed by "dnf list upgrades" | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | stan <gryt2> |
Component: | dnf | Assignee: | Packaging Maintenance Team <packaging-team-maint> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | gryt2, jsilhan, mluscon, packaging-team-maint, pnemade, rholy, tim.lauridsen, vmukhame, vondruch |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-06-04 09:41:45 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
stan
2015-06-03 20:37:15 UTC
Hello, the problem is that (like in the "dnf check-update" command) the fact that an update is available does not mean that the upgrade can be installed. It happens often e.g. when the dependencies of the update are not available yet. Especially in Rawhide. Since the "upgrade" command installs only those updates that *can* be installed (as documented), the reported behaviour is not a bug. See also http://dnf.readthedocs.org/en/latest/user_faq.html#why-are-dnf-check-update-packages-not-marked-for-upgrade-in-the-following-dnf-upgrade (the "list upgrades" command behaves the as the "check-update" command in this regard). To get the list of the updates that *can* be installed, you need to run "dnf upgrade". To see the dependency problems, you need to run "dnf --best upgrade". BTW, since you are already using Python in your workflow, I recommend you using our Python API. FYI, see also bug 1210445. (In reply to Radek Holy from comment #1) > BTW, since you are already using Python in your workflow, I recommend you > using our Python API. ...because parsing an output in an undocumented format is not very reliable solution. Thanks for your response. And the pointer to the other bugzilla. This is obviously a duplicate of the concern expressed there. Perhaps, rather than saying dependencies resolved nothing to do dnf-3 could say dependencies resolved needed dependency not available. See --best option. in this case. That is, it doesn't give the dependency chain like yum, but does indicate that it is a dependency problem. And a pointer to how to track it down. But, with the information you've provided, I can add --best always so that I see this anyway. Whoa! With the Python API I can create my own replacement for dnf. It turns dnf into a library. With a quick peruse, I didn't see how to determine if the package actually upgraded with a call, but I'll look further into creating a custom solution using it. The next time the flow breaks. Lazy evaluation. 'Why should I fix the roof, on such a sunny day?' :-) *** Bug 1239236 has been marked as a duplicate of this bug. *** |