Description of problem: Resolving Dependencies --> Running transaction check ---> Package dnf.noarch 0:0.6.3-2.fc21 will be updated --> Processing Dependency: dnf = 0.6.3 for package: dnf-plugins-extras-common-0.0.1-2.fc21.noarch ---> Package dnf.noarch 0:0.6.4-1.fc21 will be an update Packages skipped because of dependency problems: dnf-0.6.4-1.fc21.noarch from updates Version-Release number of selected component (if applicable): dnf-0.6.4-1.fc21 How reproducible: always
It seems that dnf-plugins-extras do not keep up with dnf, which has been updated recently. I think that depending on one specific version of dnf is not wise, as this issue will be repeated every time dnf receives an update and dnf-plugins-extras do not. If there is not a specific reason why to do that, I'd recommend going for ">=" relation.
BTW, I've already reported this potential problem when I was reviewing the package. I was assured that the author knows about it and that he'll release new version with every DNF version bump... To your question... We have the same problem with dnf-plugins-core. If we have ">=", there is a big chance that every DNF API change can break the plugins. If we have "=", we have to release both "dnf" and "dnf-plugins-core" every time. We need to version DNF's API somehow. Something similar to soname. I did some initial investigation but I didn't find a common practice in Python libraries yet.
(In reply to Radek Holy from comment #2) > BTW, I've already reported this potential problem when I was reviewing the > package. I was assured that the author knows about it and that he'll release > new version with every DNF version bump... > > To your question... We have the same problem with dnf-plugins-core. If we > have ">=", there is a big chance that every DNF API change can break the > plugins. If we have "=", we have to release both "dnf" and > "dnf-plugins-core" every time. We need to version DNF's API somehow. > Something similar to soname. I did some initial investigation but I didn't > find a common practice in Python libraries yet. You are absolutely correct. The API needs to be stable first for the ">=" relation not to cause any troubles, However, there is one piece of the puzzle that you did not consider. Once DNF is declared default in Fedora, the API policy needs to be quite strict, as dnf will be one of the core components. If I was exaggerating, I would say that the API needed to be absolutely stable from that point on. Realistically it will be a bit better but doing incompatible API changes between dnf minor releases will be unacceptable for the distribution. Even the last API change in hawkey caused quite a few problems that we need to avoid in the future. Considering the above, I think the ">=" relation between plugin packages will be preferred once dnf is default in Fedora.
https://admin.fedoraproject.org/updates/FEDORA-2015-1982/dnf-plugins-extras-0.0.4-1.fc21
I would be very happy if we could avoid backwards-incompatible API changes between the minor releases. Anyway, I assume that we agree that these changes can/must happen between major releases. So even in that case the ">=" relation does not work perfectly since the new major release can break the packages that depend on the earlier major release. But I admit that it seems that nobody cares about this in the Python world. At least in Fedora. And I admit that we are able to find such Fedora (!) packages and let them know that they should be prepared for the upcoming change.
arrived to stable repos