So you are seeing an error that looks similar to:
--> Starting dependency resolution
--> Finished dependency resolution
Error: package kernel-modules-extra-3.13.0-0.rc0.git3.2.fc21.i686 requires kernel-uname-r = 3.13.0-0.rc0.git3.2.fc21.i686, but none of the providers can be installed
In some cases this means a package can not be installed because it is missing some of its dependencies (i.e. DNF does not see them in any enabled repository). It can also mean a bug in the depsolving machinery. If you suspect that is the case, open a bugzilla, of course, but also execute the failing run again with --debugsolver added on the command line and attach the debugdata/ directory that will be created after the failure under the current working directory.
Typically one would use a line similar to:
$ sudo dnf --debugsolver upgrade
It is OK to zip the data or upload it somewhere public instead of the slow bugzilla (expect the zipped directory to be between five and ten megabytes). Also, if the bug is about a kernel depsolving problem we'll also need to know the particular version of kernel you are running, e.g.:
$ uname -r
3.11.100-100.fc19.x86_64
Be prepared to sometimes be told that the problem is in your particular system or that the repositories are broken. Thanks for helping us in any case.
The 0.4.8 was just released today (release notes). The focal point was to add more crucial pieces to the API and there are still areas where we lag, but at least we're starting to get some feedback and discussion running on the API.
In Fedora we are shipping python3-dnf package now. The package supplying /usr/bin/dnf is still the Python 2 DNF package, so when you run dnf upgrade etc, from the command line it is executed under the current Python (unless forced by e.g. /usr/bin/python3 /usr/bin/dnf upgrade). We're ready to drop Python 2 support as soon as Anaconda is running the Py3 DNF. Extension authors should start new projects with the Py3 package.
Other than that there are some bugfixes in the release, including support for installing packages from http, better installs from a pathname and listing comps environments in dnf group list.
We're releasing 0.4.7 today. Besides fixing a couple of bugs described in the release notes, we start to deliver DNF API with this release. In practice, those of you who have been waiting for the API to be published to write a plugin or an extension can start poking around. Use however only those things described in the documentation. We will not fall into the same trap Yum did in maintaining every class and every method that was ever declared in the code. On the other hand, if it's in the docs it's guaranteed to stay there with the same semantics or be duly deprecated. If it's not in the docs and you need it, give us a holler.
Edit: Here's the F20 update
Are you missing your favorite Yum feature in DNF? Or you thought of an entirely new one? Just CC yourself on those feature requests and bugs that you'd prefer get fixed first and we'll notice. It also works for those bugs that we originally decided not to fix.
There's a bugzilla query showing all opened DNF bugs and if a particular request is missing be sure to open one.0.4.6 brings two new major features and much more. Firstly, a series of patches revives the history undo command, so transactions can be reverted now. In essence undoing a transaction is performing its inverse transaction. There is a couple of things worth mentioning to this: if one package replaced another in the original transaction than to perform the undo the original package needs to be available in a repository somewhere and also if RPM fails to validate the inverse transaction (typically because of dependency errors), then that's it, DNF will not force it. So keep your RPMDB consistent and healthy at all times and if a package is missing mail your favorite Fedora infra admin about the way we remove superseded packages from the update repos.
Secondy, DNF will now limit the number of installed kernels and installonly packages in general to the number specified by installonly_limit in the config. People who got bitten by having 15 kernels installed and running out of space on /boot shall suffer no more.
There are vast internal changes to dnf.cli, the subpackge that provides CLI in DNF. In particular, it is now better separated from the core which in turns allows simplification of some unit tests and makes (the up and coming) API more reasonable. Oh and saves us a a lot of "WTF is that?" from new upstream contributors.
The hawkey library used against DNF from with this versions uses a recent RPMDB
loading optimization in libsolv that shortens DNF startup by seconds when the cached RPMDB is invalid. This generally applies in every DNF run after the RPMDB has changed (for instance the previous DNF run did an installation). Measured on a box with a mid-range SSD and all around average specs, the RPMDB load time itself drops from 1900 ms to about 150 ms. Not bad, but all the credit for this really goes to Michael Schroeder of the SUSE/libsolv fame.
We have also added further fixes to support Python 3 and enabled librepo's
fastestmirror caching optimization so the slowdown some of us have observed after enabling fastestmirror few releases back should get reduced again.
Please also see the 0.4.6 release notes for a complete list of bugs fixed.