it don't matter which RPM's - my own repos have metadata_expire=30m, dnf-cache-timers are disabled by intention and it happens nearly regulary when do a "dnf update /downloads/*.rpm" the first time when it downloads the metadata (for whatever reason, see other bugreport)
whenever that happens, just cursor-up + enter and it works fine

https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting#dependency-resolution-problem would not be needed if DNF would behave somehow similar to YUM and clearly show *what* it thinks is wrong with dependencies up to libnames and libsonames
with DNF it's completly impossible to just look at the output and find out which package is repsonsible to maybe consider removing this one completly from the system
all that "only shiny output for noobs to not overwheelm them" is harmful, they noob users typically don't use DNF/YUM in the terminal and the advanced users now need to debug and dig for infos which where just visible many years and frankly *that informations* leaded that i was ablke to understand how all the deps and packages work together - starting today with Linux would mean i never reach the level of knowledge i have today
JUST GIVE OUT THE DEPENDECY PROBLEMS ON THE TERMINAL
"I didn't get what you report in your other comments" -> well, i didn't get what DNF is trying to report - there is no way to know if it's just another random and wrong "i can't solve deps" or a real problem nor what dependency - and please don't come with the *way too large* logs where you need to find a needle in the haystack
another problem: that logs and the size of /var/cache/dnf are as big as complete server setups including userdata here........

the outpout i see most often from dnf is "is not installable" while it is just NOT true, sometimes a second try suceeds, in cases like below it's just too stupid that the pretended "dhcp-compat-12:4.3.3-6.fc23.x86_64 is not installable" is the root-cause for "nothing provides dhcp-common = 12:4.3.3-6.fc23"
_________________________________________________________________________
--> Starting dependency resolution
--> Finished dependency resolution
Error: nothing provides dhcp-common = 12:4.3.3-6.fc23 needed by dhcp-client-12:4.3.3-6.fc23.x86_64.
package dhcp-common-12:4.3.3-6.fc23.noarch is not installable.
package dhcp-compat-12:4.3.3-6.fc23.x86_64 is not installable.
package dhcp-libs-12:4.3.3-6.fc23.x86_64 is not installable.
package dhcp-relay-12:4.3.3-6.fc23.x86_64 is not installable.
package dhcp-server-12:4.3.3-6.fc23.x86_64 is not installable.
package grep-2.22-1.fc23.x86_64 is not installable.
package nss-3.20.1-1.0.fc23.x86_64 is not installable.
package nss-sysinit-3.20.1-1.0.fc23.x86_64 is not installable.
package nss-tools-3.20.1-1.0.fc23.x86_64 is not installable
(try to add '--allowerasing' to command line to replace conflicting packages)
_________________________________________________________________________
[root@rh:/downloads]$ yum-deprecated update *.rpm
Yum command has been deprecated, use dnf instead.
See 'man dnf' and 'man yum2dnf' for more information.
Loaded plugins: etckeeper
Examining dbus-1.10.2-1.fc23.x86_64.rpm: 1:dbus-1.10.2-1.fc23.x86_64
Marking dbus-1.10.2-1.fc23.x86_64.rpm as an update to 1:dbus-1.10.0-1.fc23.x86_64
Examining dbus-libs-1.10.2-1.fc23.x86_64.rpm: 1:dbus-libs-1.10.2-1.fc23.x86_64
Marking dbus-libs-1.10.2-1.fc23.x86_64.rpm as an update to 1:dbus-libs-1.10.0-1.fc23.x86_64
Examining dbus-x11-1.10.2-1.fc23.x86_64.rpm: 1:dbus-x11-1.10.2-1.fc23.x86_64
Marking dbus-x11-1.10.2-1.fc23.x86_64.rpm as an update to 1:dbus-x11-1.10.0-1.fc23.x86_64
Examining dhcp-client-4.3.3-6.fc23.x86_64.rpm: 12:dhcp-client-4.3.3-6.fc23.x86_64
Marking dhcp-client-4.3.3-6.fc23.x86_64.rpm as an update to 12:dhcp-client-4.3.3-5.fc23.x86_64
Examining dhcp-common-4.3.3-6.fc23.noarch.rpm: 12:dhcp-common-4.3.3-6.fc23.noarch
Marking dhcp-common-4.3.3-6.fc23.noarch.rpm as an update to 12:dhcp-common-4.3.3-5.fc23.noarch
Examining dhcp-compat-4.3.3-6.fc23.x86_64.rpm: 12:dhcp-compat-4.3.3-6.fc23.x86_64
Marking dhcp-compat-4.3.3-6.fc23.x86_64.rpm as an update to 12:dhcp-compat-4.3.3-5.fc23.x86_64
Examining dhcp-libs-4.3.3-6.fc23.x86_64.rpm: 12:dhcp-libs-4.3.3-6.fc23.x86_64
Marking dhcp-libs-4.3.3-6.fc23.x86_64.rpm as an update to 12:dhcp-libs-4.3.3-5.fc23.x86_64
Examining dhcp-relay-4.3.3-6.fc23.x86_64.rpm: 12:dhcp-relay-4.3.3-6.fc23.x86_64
Marking dhcp-relay-4.3.3-6.fc23.x86_64.rpm as an update to 12:dhcp-relay-4.3.3-5.fc23.x86_64
Examining dhcp-server-4.3.3-6.fc23.x86_64.rpm: 12:dhcp-server-4.3.3-6.fc23.x86_64
Marking dhcp-server-4.3.3-6.fc23.x86_64.rpm as an update to 12:dhcp-server-4.3.3-5.fc23.x86_64
Examining grep-2.22-1.fc23.x86_64.rpm: grep-2.22-1.fc23.x86_64
Marking grep-2.22-1.fc23.x86_64.rpm as an update to grep-2.21-7.fc23.x86_64
Examining nss-3.20.1-1.0.fc23.x86_64.rpm: nss-3.20.1-1.0.fc23.x86_64
Marking nss-3.20.1-1.0.fc23.x86_64.rpm as an update to nss-3.20.0-1.3.fc23.x86_64
Examining nss-sysinit-3.20.1-1.0.fc23.x86_64.rpm: nss-sysinit-3.20.1-1.0.fc23.x86_64
Marking nss-sysinit-3.20.1-1.0.fc23.x86_64.rpm as an update to nss-sysinit-3.20.0-1.3.fc23.x86_64
Examining nss-tools-3.20.1-1.0.fc23.x86_64.rpm: nss-tools-3.20.1-1.0.fc23.x86_64
Marking nss-tools-3.20.1-1.0.fc23.x86_64.rpm as an update to nss-tools-3.20.0-1.3.fc23.x86_64
Resolving Dependencies
--> Running transaction check
---> Package dbus.x86_64 1:1.10.0-1.fc23 will be updated
---> Package dbus.x86_64 1:1.10.2-1.fc23 will be an update
---> Package dbus-libs.x86_64 1:1.10.0-1.fc23 will be updated
---> Package dbus-libs.x86_64 1:1.10.2-1.fc23 will be an update
---> Package dbus-x11.x86_64 1:1.10.0-1.fc23 will be updated
---> Package dbus-x11.x86_64 1:1.10.2-1.fc23 will be an update
---> Package dhcp-client.x86_64 12:4.3.3-5.fc23 will be updated
---> Package dhcp-client.x86_64 12:4.3.3-6.fc23 will be an update
---> Package dhcp-common.noarch 12:4.3.3-5.fc23 will be updated
---> Package dhcp-common.noarch 12:4.3.3-6.fc23 will be an update
---> Package dhcp-compat.x86_64 12:4.3.3-5.fc23 will be updated
---> Package dhcp-compat.x86_64 12:4.3.3-6.fc23 will be an update
---> Package dhcp-libs.x86_64 12:4.3.3-5.fc23 will be updated
---> Package dhcp-libs.x86_64 12:4.3.3-6.fc23 will be an update
---> Package dhcp-relay.x86_64 12:4.3.3-5.fc23 will be updated
---> Package dhcp-relay.x86_64 12:4.3.3-6.fc23 will be an update
---> Package dhcp-server.x86_64 12:4.3.3-5.fc23 will be updated
---> Package dhcp-server.x86_64 12:4.3.3-6.fc23 will be an update
---> Package grep.x86_64 0:2.21-7.fc23 will be updated
---> Package grep.x86_64 0:2.22-1.fc23 will be an update
---> Package nss.x86_64 0:3.20.0-1.3.fc23 will be updated
---> Package nss.x86_64 0:3.20.1-1.0.fc23 will be an update
---> Package nss-sysinit.x86_64 0:3.20.0-1.3.fc23 will be updated
---> Package nss-sysinit.x86_64 0:3.20.1-1.0.fc23 will be an update
---> Package nss-tools.x86_64 0:3.20.0-1.3.fc23 will be updated
---> Package nss-tools.x86_64 0:3.20.1-1.0.fc23 will be an update
--> Finished Dependency Resolution

just look at https://bugzilla.redhat.com/show_bug.cgi?id=1263888#c12 with no single feedback from the developers - they would NOT need any debug data, just try it out with random packages containing sub-package dependencies
"non deterministically" is plain wrong
IT IS deterministically with local packages
the kernel above was a ordinary "dnf upgrade"
harry@srv-rhsoft:~]$ rpm -q libsolv
libsolv-0.6.15-1.fc23.x86_64

comment 14 was only a side note - you got it?
please realize that this *only* would solve regular kernel updates, wehn you look at bodhi i typically download kernels from koji and then we are at the *real* topic of this bugreport that DNF don't work and never worked proper with "dnf update *.rpm" - period

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.
Thank you for reporting this bug and we are sorry it could not be fixed.

dunno what is there useless - that's what it gave out while pretended that deps are broken while not realize that the pretended missing one is within * on the command line
that typically happens everytime when "dnf update *.rpm" has involved sub-packages with version-dependencies between the local rpm packages
well, it's a longer time since a touched DNF bedcause "yum --disablerepo=\* update *.rpm" works relieable and without download metadata where DNF cries that no repo is available

it's interesting that you don't take "systemd-compat-libs" into the game since the error is "nothing provides systemd-libs(x86-64) = 229-9.fc24 needed by systemd-compat-libs-229-9.fc24.x86_64" and without that package in the transaction the *real problem* that DNF is unable to solve such deps when the required versioned dependencie is part of the local files

"dnf --disablerepo=\* -C update ./*.rpm" - so why can't you just do the same as the reporter?
we had also cases where DNF pretended unsolveable deps without mention what is the problem when metadata of a repo with a short cachetime where refreshed due "dnf update *.rpm"
just press cursor-up+enter and suddenly it worked - multiple times, for multiple transactions - look at the bugreports from last year

ok, so i will try later or tomorrow on a VM downgrade and upgrade with debuginfos, now then we at least are trying to do the same and there is feedback not like the last time where nothing came back after provide the requested data until yesterday
2015-11-09 11:23:13 EST
attach the debugdata, please
2015-11-13 06:30 EST
here are your debugdata (7.44 MB, application/octet-stream)
2016-07-08
This package has changed ownership
2016-07-21
That debugdata is useless
while i still don't get *what* is useless there

i really have no idea *why* DNF acts *that non deterministically*
just downgraded systemd to the 229-8.fc24 build, dnf update *.rpm with the downloads -> works this time fine (3 attempts, 1 downloaded repo-metadata too) and so it seems we really need to figure out what in the debugdata from "2015-11-13 06:30" is unusable since they are generated as advised

(In reply to Harald Reindl from comment #37)
> i really have no idea *why* DNF acts *that non deterministically*
>
> just downgraded systemd to the 229-8.fc24 build, dnf update *.rpm with the
> downloads -> works this time fine (3 attempts, 1 downloaded repo-metadata
> too) and so it seems we really need to figure out what in the debugdata from
> "2015-11-13 06:30" is unusable since they are generated as advised
I guess this has been fixed at some point in DNF. We had a lot of releases since that.

no, i can't give a clear reproducer, i just see that behavior often from day one and in most cases where i intend to update a bnuch of packages from koji downloads i started to use yum-deprecated in general to prevent anger since my goal is test packages and give karma as soon it is possible and makes sense
also that "dnf --disablerepo=\*" by default don't work without add another param is annoying because when i know that all deps are solveable with the local files provided there is no need to download metadata (yum in the past did that only when it had to solve a additional dependency and was degraded in that context in the meantime too)

if that debugdata is again not useable i suggest dnf developers starting to fix that so users can at least provide useful informations
DNF in general is very silent in case of dependency errors compared to YUM which tells you files and sonames where problems are - well in that case it's clear that it can't output something useful because there is no problem in the deps but in DNF or it's libraries
given how long we are now punished with deprecation warnings while tehre is still no full replacement of "yum-utils" (especially package-cleanup and repomanage --old) and critical things like "yum --security update" are also still missing people get REALLY tired
[root@srv-rhsoft:~]$ rpm -qa | grep dnf
python3-dnf-1.1.10-1.fc24.noarch
dnf-1.1.10-1.fc24.noarch
dnf-plugins-core-0.1.21-3.fc24.noarch
dnf-conf-1.1.10-1.fc24.noarch
python3-dnf-plugins-core-0.1.21-3.fc24.noarch
dnf-yum-1.1.10-1.fc24.noarch
etckeeper-dnf-1.18.5-1.fc24.noarch
[root@srv-rhsoft:~]$ rpm -q hawkey
hawkey-0.6.3-5.fc24.x86_64
[root@srv-rhsoft:~]$ rpm -q libsolv
libsolv-0.6.23-2.fc24.x86_64

basically something is wrong here:
str2job: unknown package 'pcre-devel-8.39-3.fc24.x86_64@@commandline'
which is really weird. Looking more.
> package-cleanup
It never worked correctly. Though there is some replacement for it in DNF itself.
> repomanage
it's in dnf-plugins-extras for long time.

package-cleanup --leaves --all as well as --orphans are working correctly here for many years while the replacements in DNF rely on /var/lib/dnf instead of the rpm databas itself which makes them completely fragile and useless

Because the package is disabled. This is a bug, of course, the testcase reader should still use the package even if it is disabled. I'll change the code.
But I guess dnf should not exclude packages from the command line when you do --disablerepo=\*. It should only disable "real" repos.

So after all I was able to reproduce on DNF 2.0...
[brain@brain python-serpy]$ sudo dnf install ./openssl-* --debugsolver
[sudo] password for brain:
Last metadata expiration check: 0:28:16 ago on Mon Nov 14 17:07:56 2016 CET.
Failed to synchronize cache for repo 'rhpkg-rawhide', disabling.
Error:
Problem 1: problem with installed package authconfig-6.2.10-14.fc25.x86_64
- package authconfig-6.2.10-14.fc25.x86_64 requires /usr/bin/openssl, but none of the providers can be installed
- package authconfig-6.2.10-14.fc25.x86_64 requires /usr/bin/openssl, but none of the providers can be installed
- cannot install both openssl-1:1.1.0b-4.fc26.x86_64 and openssl-1:1.1.0c-1.fc26.x86_64
- cannot install both openssl-1:1.1.0b-4.fc26.x86_64 and openssl-1:1.1.0c-1.fc26.x86_64
- conflicting requests
Problem 2: problem with installed package realmd-0.16.2-5.fc25.x86_64
- package realmd-0.16.2-5.fc25.x86_64 requires authconfig, but none of the providers can be installed
- package realmd-0.16.2-5.fc25.x86_64 requires authconfig, but none of the providers can be installed
- package authconfig-6.2.10-14.fc25.x86_64 requires /usr/bin/openssl, but none of the providers can be installed
- package authconfig-6.2.10-14.fc25.x86_64 requires /usr/bin/openssl, but none of the providers can be installed
- package openssl-1:1.1.0c-1.fc26.x86_64 requires openssl-libs(x86-64) = 1:1.1.0c-1.fc26, but none of the providers can be installed
- package openssl-1:1.1.0c-1.fc26.x86_64 requires openssl-libs(x86-64) = 1:1.1.0c-1.fc26, but none of the providers can be installed
- cannot install both openssl-libs-1:1.1.0b-4.fc26.x86_64 and openssl-libs-1:1.1.0c-1.fc26.x86_64
- cannot install both openssl-libs-1:1.1.0b-4.fc26.x86_64 and openssl-libs-1:1.1.0c-1.fc26.x86_64
- conflicting requests
Problem 3: problem with installed package fprintd-pam-0.7.0-1.fc26.x86_64
- package fprintd-pam-0.7.0-1.fc26.x86_64 requires authconfig, but none of the providers can be installed
- package fprintd-pam-0.7.0-1.fc26.x86_64 requires authconfig, but none of the providers can be installed
- package authconfig-6.2.10-14.fc25.x86_64 requires /usr/bin/openssl, but none of the providers can be installed
- package authconfig-6.2.10-14.fc25.x86_64 requires /usr/bin/openssl, but none of the providers can be installed
- package openssl-1:1.1.0c-1.fc26.x86_64 requires openssl-libs(x86-64) = 1:1.1.0c-1.fc26, but none of the providers can be installed
- package openssl-1:1.1.0c-1.fc26.x86_64 requires openssl-libs(x86-64) = 1:1.1.0c-1.fc26, but none of the providers can be installed
- cannot install both openssl-libs-1:1.1.0b-4.fc26.x86_64 and openssl-libs-1:1.1.0c-1.fc26.x86_64
- cannot install both openssl-libs-1:1.1.0b-4.fc26.x86_64 and openssl-libs-1:1.1.0c-1.fc26.x86_64
- package openssl-devel-1:1.1.0b-4.fc26.x86_64 requires openssl-libs(x86-64) = 1:1.1.0b-4.fc26, but none of the providers can be installed
- conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages)
but then I do:
[brain@brain python-serpy]$ testsolv -r debugdata/testcase.t
downgrade openssl-1:1.1.0c-1.fc26.x86_64@@System openssl-1:1.1.0b-4.fc26.x86_64@@commandline
downgrade openssl-devel-1:1.1.0c-1.fc26.x86_64@@System openssl-devel-1:1.1.0b-4.fc26.x86_64@@commandline
downgrade openssl-libs-1:1.1.0c-1.fc26.x86_64@@System openssl-libs-1:1.1.0b-4.fc26.x86_64@@commandline
which is now able to find solution.

thanks for changing priority to high while i am not teriible happy with "24 -> rawhide" since that's the major reason i *must* use yum-deprecated in a lot of environments and the deprectaion warnings when i already call "yum-deprecated" by name making me angry for a long time now (especially since they spit into cron-mails)

(In reply to Vít Ondruch from comment #61)
> (In reply to Igor Gnatenko from comment #60)
> But that suggest to me that the "commandline" repo is not treated properly
> by DNF. I.e. not all the data are fed to the internal solver.
Yes.
* Provides (probably local) are not loaded correctly
* Not all rpms loaded into pool.
I guess one of these options.

Recently we refactored install and upgrade commands and package handling. Please can you try upstream version of dnf-2.0 from our testing repository ("dnf copr enable rpmsoftwaremanagement/dnf-nightly")? We will be very happy to hear your feedback. Thanks a lot

i fear that stuff is for F25+ - i did not change the fedora version to "rawhide" and there are no machines with F25 planned the next 2-3 months for several reasons
[root@srv-rhsoft:~]$ dnf copr enable rpmsoftwaremanagement/dnf-nightly
You are about to enable a Copr repository. Please note that this
repository is not part of the main Fedora distribution, and quality
may vary.
The Fedora Project does not exercise any power over the contents of
this repository beyond the rules outlined in the Copr FAQ at
<https://fedorahosted.org/copr/wiki/UserDocs#WhatIcanbuildinCopr>, and
packages are not held to any quality or security level.
Please do not file bug reports about these packages in Fedora
Bugzilla. In case of problems, contact the owner of this repository.
Do you want to continue? [y/N]: y
Error: This repository does not have any builds yet so you cannot enable it now.

> Please try it again on Fc24+ system
what was unclear in "and there are no machines with F25 planned the next 2-3 months for several reasons" when this bug was initially reported for F22 and some smart guy thought it's cool to change it to rawhide?

Please try it on fc24 system. In that repo there are available dnf packages as follows:
dnf-0:2.0.0_1-33gf0093d6.fc24.noarch
dnf-0:2.0.0_1-33gf0093d6.fc24.src
dnf-0:2.0.0_1-34g53fb86c.fc24.noarch
dnf-0:2.0.0_1-34g53fb86c.fc24.src
dnf-0:2.0.0_1-37g4cea33d.fc24.noarch
dnf-0:2.0.0_1-37g4cea33d.fc24.src
dnf-0:2.0.0_1-40gdb7f88b.fc24.noarch
dnf-0:2.0.0_1-40gdb7f88b.fc24.src
dnf-0:2.0.0_1-45ga03ea5a.fc24.noarch
dnf-0:2.0.0_1-45ga03ea5a.fc24.src
dnf-0:2.0.0_1-51g2148ca7.fc24.noarch
dnf-0:2.0.0_1-51g2148ca7.fc24.src
dnf-0:2.0.0_1-59gaa9ebc1.fc24.noarch
dnf-0:2.0.0_1-59gaa9ebc1.fc24.src
Last versions of DNF-2.0 contain unification of local package handling with packages from repo, therefore there shouldn't be any differences according to package source. Please try it on fc24 system that is the oldest supported fedora. Your experience with latest upstream version is critical for further dnf tuning and development. Thanks a lot for your time and feedback.

and what doe sthat mean in context of "Please try it on fc24 system. In that repo there are available dnf packages as follows" - *where* are the packages for F24?
"problem to reproduce original issue" - well, just get a F24 machine install the bind packages above in lower version, download the fresh builds from koji and try "dnf update *.rpm" - that don#t always happen in every combination and hence i am really annoyed by the unpreditability of the new proposed package manager for longer than a year while the old one just works fine as it did the past 10 years

I am talking about this repo: dnf copr enable rpmsoftwaremanagement/dnf-nightly
.repo file contains:
[rpmsoftwaremanagement-dnf-nightly]
name=Copr repo for dnf-nightly owned by rpmsoftwaremanagement
baseurl=https://copr-be.cloud.fedoraproject.org/results/rpmsoftwaremanagement/dnf-nightly/fedora-$releasever-$basearch/
type=rpm-md
skip_if_unavailable=True
gpgcheck=1
gpgkey=https://copr-be.cloud.fedoraproject.org/results/rpmsoftwaremanagement/dnf-nightly/pubkey.gpg
repo_gpgcheck=0
enabled=1
enabled_metadata=1
Additionally I tested it on VM with:
rpm-4.13.0_alpha-487gd1c988b.fc24.x86_64
dnf-2.0.0_1-59gaa9ebc1.fc24.noarch
libdnf-0.7.1-2gfe5a08b.fc24.x86_64
libsolv-0.6.24-15g50fc549.fc24.x86_64
python2-dnf-2.0.0_1-59gaa9ebc1.fc24.noarch
python3-dnf-2.0.0_1-59gaa9ebc1.fc24.noarch
It works like expected. I downgrade it as much as possible and it was working also.
Probably can you try "dnf check" command?
Or --allowerasing option with upgrade command, just to see what happens.
Or as attachment output from 'rpm -qa', or system specification, like free memory on that system.

(In reply to Jaroslav Mracek from comment #77)
> It works like expected. I downgrade it as much as possible and it was
> working also.
I wasn't able to find some steps which would reproduce it in 100% of cases. Though I don't think it's related to DNF itself, I suppose libdnf.
>
> Probably can you try "dnf check" command?
>
> Or --allowerasing option with upgrade command, just to see what happens.
Absolutely nothing, same results.
>
> Or as attachment output from 'rpm -qa', or system specification, like free
> memory on that system.
That's not related.

Ok, please try 'dnf --allowerasing --enablerepo dnf-nightly upgrade dnf'
or
'dnf --allowerasing --best --enablerepo dnf-nightly upgrade dnf'
I am sure that you will like the dnf-2.0. Many fixes are there and only there including many new features.

Created attachment 1240376[details]
dnf-extras that should be installable
Please can you try to update system with provided rpms of extras. It should help to overcome the problem with dnf-plugins-extras provides

Created attachment 1240395[details]
Fc24 extras
Sorry for previous build for Fc25. This one is for Fc24. The rest of related packages should be installed from repos as you mentioned. I try to get clue whats wrong as fast as it is possible.

frankly how do you imagine to solve that chicken-egg-problem installing packages from the attachment and what is the problem not be able to add them to the repo in the last few days?
[root@srv-rhsoft:/downloads/extras-fc24]$ rpm -Uvh python3-dnf-plugins-extras-show-leaves-0.10.0-1.git.283.dda3720.fc24.noarch.rpm python3-dnf-plugins-extras-common-0.10.0-1.git.283.dda3720.fc24.noarch.rpm python3-dnf-plugins-extras-repomanage-0.10.0-1.git.283.dda3720.fc24.noarch.rpm dnf-plugins-extras-common-data-0.10.0-1.git.283.dda3720.fc24.noarch.rpm python3-dnf-plugins-extras-leaves-0.10.0-1.git.283.dda3720.fc24.noarch.rpm
error: Failed dependencies:
python3-dnf >= 2.0 is needed by python3-dnf-plugins-extras-common-0.10.0-1.git.283.dda3720.fc24.noarch

OK, using the old dnf was in that case able to solve the deps and it also looks like the new one was at least able to update the bind-packages from donwloads-folder
anyways, the repo should be complete!
dnf --enablerepo=dnf-nightly install python3-dnf-plugins-extras-show-leaves-0.10.0-1.git.283.dda3720.fc24.noarch.rpm python3-dnf-plugins-extras-common-0.10.0-1.git.283.dda3720.fc24.noarch.rpm python3-dnf-plugins-extras-repomanage-0.10.0-1.git.283.dda3720.fc24.noarch.rpm dnf-plugins-extras-common-data-0.10.0-1.git.283.dda3720.fc24.noarch.rpm python3-dnf-plugins-extras-leaves-0.10.0-1.git.283.dda3720.fc24.noarch.rpm

and it don't really work proper
first "dnf upgrade" on my second machien showed some updates in know they are there, solved deps and than spit out a ton of xml errors - after "rm -rf /var/cache/dnf/*" repeatly repos disabled and no mentioning why
dnf2 still don't report the reasons *why* dependencies can not be solved and only list affected packages - i want my times back where the package manager was a solid base on Fedora and talked clearly what are the problems
[root@rh:~]$ dnf upgrade
Last metadata expiration check: 0:00:13 ago on Mon Jan 16 14:54:29 2017 CET.
Failed to synchronize cache for repo 'fedora', disabling.
Failed to synchronize cache for repo 'updates-testing', disabling.
Failed to synchronize cache for repo 'updates', disabling.
Dependencies resolved.
Nothing to do.
Complete!

thank you for nothing - hopefully i can downgrade DNF to something working - my feelings for DNF2 and not "I am sure that you will like the dnf-2.0" are the opposite, when i disable all repos with --disablerepo=\* --enablerepo=myown it works, as usually DNF don't give any usefull output and so the "INSUFFICIENT_DATA" are because it works like a damned blackbox as it always did while YUM for so many years gave useful informations WHY things are going wrong which where alaways helpful to nail down issues with packages and dependencies
DNF is designed for a sunny world not overwhlem the ordianry user with informations while the developers don't get the the ordinary user is not the target the are developing for because the ordianry user typically don't use DNF or YUM at all

The problem described in Comment 97 looks like that libsolv do not take correctly files provides from @commandline repo. I refactored repoquery to accept .rpm and with -l option it shows that vim-minimal-8.0.086-1.fc26.x86_64.rpm has /usr/bin/vi file.
I am creating libsolv issue.

I AM that 3rd party
so what are the *exact* replacements for that and how do you imagine making people happy when you permanently chnage packaging and options?
the same for rename options back to "includepkgs" and "excludepkgs"
i told you guys that it is a bad idea as you renamed it to "exclude" and "include" for no good reason, but i was blamed with a larg eportion of arrogance to shutup and that you are NDF not YUM
now you change it again in the oother direction and each and every admin out tthere needs to revert a previous harmful change again - stop kidding users please

> we will not introduce it again
yeah because you are DNF
every other package in the Fedora world would just define a metapackage pulling *all* subpackages as a soft-dep which can be removed and then you could also remove un-needed subpackages without any downsides for the users and 3rd parties

(In reply to Harald Reindl from comment #104)
> > we will not introduce it again
>
> yeah because you are DNF
>
> every other package in the Fedora world would just define a metapackage
> pulling *all* subpackages as a soft-dep which can be removed and then you
> could also remove un-needed subpackages without any downsides for the users
> and 3rd parties
and 1) get it back after update 2) cause lots of problems, because e.g. you don't have FS/setup which supports snapshots (hi snapper plugin)
It doesn't make any sense to pull all plugins if 90% of them will just print errors and install ton of useless dependencies.

it also don't make sense introduce all the time arbitrary changes forth and back especially when the where flamewars in the past not to intrduce some of that changes from the begin and now after they got sucked and adopted by users change it back
where is the documentation what i need to change instead define "dnf-plugins-extras" als requirement to make sure all teh cureently installed features are unchanged present
it took long enough the get man yof the yum features back and something like "yum --security update" is still missing
another arbitrary change i saw the sohort tinmeframe with the broken DNF2.0 on 24 the script below was no longer quite and asked for something spitting a "Y" every day in a cron mail - in the past the same script with YUM used --security on production servers - viola cron mails only if there are new scurity updates, worked like a charm for years and since "yum-deprecated" even if called explicit warns about deprecation of yum no longer useable
[root@srv-rhsoft:~]$ cat /etc/cron.daily/check-updates.cron
#!/bin/bash
yum_output=`LANG=C; /usr/bin/dnf -q check-update`
echo $yum_output | xargs | sed 's/ updates//g' | tr -d '\n'

(In reply to Harald Reindl from comment #103)
> I AM that 3rd party
>
> so what are the *exact* replacements for that
If you are calling plugins from bash then:
`Requires: dnf-command(<nameofplugincommand>)` [1]
If you require passive plugin (unlikely) then:
`Requires: dnf-plugins-extras-<nameofplugin>`
If it's calling Python API then:
`Requires: python[23]-dnf-plugins-extras-<nameofplugin>`
> and how do you imagine making
> people happy when you permanently chnage packaging and options?
>
> the same for rename options back to "includepkgs" and "excludepkgs"
> ...
> i told you guys that it is a bad idea as you renamed it to "exclude" and
> "include" for no good reason, but i was blamed with a larg eportion of
> arrogance to shutup and that you are NDF not YUM
>
> now you change it again in the oother direction and each and every admin out
> tthere needs to revert a previous harmful change again - stop kidding users
> please
we have at least tried to make it as much as compatible as before in DNF-1 so `include` should still work. This all was part of bigger change in DNF-2.0. I am sorry for issues but these intentional changes were done for making DNF compatible with yum (when the compatibility was broken). It was done at once to don't change DNF behaviour or API in following years.
[1] http://dnf.readthedocs.io/en/latest/command_ref.html#description

I'm reading this ticket because I came across this in the folloing manner trying to test a new build of chromium
At the date of this ticket, and on F25, the current chromium version is:
chromium.x86_64 55.0.2883.87-1.fc25
The advisory for the 56 update is: FEDORA-2017-583538ec31
mkdir chromium56_update && cd chromium56_update
bodhi -D chromium-56.0.2924.87-3.fc25

The command 'dnf upgrade' cannot be used for packages that are not installed. From your report we cannot see your version of dnf and libdnf and what behavior you expect. I also think that it is not related to the bug report. The problem in this bug was solved in libdnf and how to get upstream version can be found in Comment 66. So far from presented information I don't see the behavior as a bug.

They were installed, sorry if I wasn't clear about that but I started off with Chromium 55 installed as normal. You can clearly see the difference in behavior between before the packages have been installed, and after they have been downgraded and the same command is run (i.e. It then resolves correctly.) Same command.
It is a bug.

Since nobody has Chromium 56 installed since it's not in testing yet, try it right now with an up-to-date system. You have until 56 makes it into stable, but to answer your question about me I'm fully up-to-date with -testing enabled.