Description of problem: We have specified following BR in rubygem-actionmailer [1]: BuildRequires: rubygem(minitest) >= 5.1.0 BuildRequires: rubygem(minitest) <= 5.3.1 Since there is implicit AND between lines, one would expect, that this will install package rubygem(minitest) >= 5.1.0 AND rubygem(minitest) <= 5.3.1, but surprisingly, this [2] is what DNF installs: DEBUG util.py:393: rubygem-minitest noarch 5.8.1-1.fc24 build 42 k DEBUG util.py:393: rubygem-minitest4 noarch 4.7.0-5.fc23 build 43 k Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: rubygem-minitest.noarch 5.8.1-1.fc24 and rubygem-minitest4.noarch 4.7.0-5.fc23 are installed Expected results: The build should fail, since there is no rubygem-minitest package with version in between 5.1.0 and 5.3.1 Additional info: [1] http://pkgs.fedoraproject.org/cgit/rubygem-actionmailer.git/tree/rubygem-actionmailer.spec#n30 [2] https://kojipkgs.fedoraproject.org//packages/rubygem-actionmailer/4.2.5/1.fc24/data/logs/noarch/root.log
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
RPM threats
Requires are matched against provides not package names (only). I assume that rubygem-minitest4-4.7.0-5.fc23 Provides: rubygem-minitest = 4.7.0-5 This means that both Requires are fulfilled with those two packages. Unfortunately there is no mean in RPM right now to link the two Requires: lines together in a way that they have to be fulfilled with one exact package.
RPM threats those dependencies as different requirements. I think we need to introduce syntax for: 5.1.0 <= FooBar <= 5.3.0
One work around is adding BuildConflicts: rubygem(minitest) < 5.1.0 and may be even BuildConflicts: rubygem(minitest) > 5.3.1 Note that this has not quite the same semantics as a Requirement for a version range as it actively prevents versions outside of the range being installed which in theory could create additional problems. It should just work for most cases, though.
*** This bug has been marked as a duplicate of bug 1389871 ***