dnf repoquery defaults --alldeps to off. This is not a good default for whatrequires queries, the use case where one would want to search for exactly the given string is rare compared to alldeps. For this reason, yum-utils' repoquery has --alldeps on by default, and provides --exactdeps to negate it. IMO dnf repoquery should do the same.
*** Bug 1245137 has been marked as a duplicate of this bug. ***
I would rather introduce `--whatneeds` option to query Which would be shortcut for `--whatrequires --alldeps --whatsuggests --whatrecommends`. Lets see how the weak deps will be used and wait for other user opinions.
dnf repoquery --whatrequires is broken on Fedora 21. dnf --version 0.6.4 Installed: dnf-0:0.6.4-7.fc21.noarch at 2015-10-13 17:53 Built : Fedora Project at 2015-09-23 14:30 Installed: rpm-0:4.12.0.1-7.fc21.x86_64 at 2015-07-29 03:47 Built : Fedora Project at 2015-06-15 07:10 I don't have options --alldeps ,only have --conflicts | --enhances | --obsoletes | --provides | --recommends | --requires | --suggests | --supplements dnf repoquery --whatrequires libmtp Using metadata from Tue Oct 13 19:16:32 2015 (2 days, 6:17:05 hours old) libmtp-devel-0:1.1.8-1.fc21.i686 libmtp-devel-0:1.1.8-1.fc21.x86_64 libmtp-examples-0:1.1.8-1.fc21.x86_64 libmtp-devel-0:1.1.9-1.fc21.i686 libmtp-devel-0:1.1.9-1.fc21.x86_64 libmtp-examples-0:1.1.9-1.fc21.x86_64 repoquery --whatrequires libmtp amarok-0:2.8.0-11.fc21.x86_64 amarok-0:2.8.0-17.fc21.x86_64 calibre-0:2.10.0-1.fc21.x86_64 calibre-0:2.23.0-1.fc21.x86_64 cantata-0:1.4.1-1.fc21.x86_64 clementine-0:1.2.3-1.fc21.x86_64 clementine-0:1.2.3-10.fc21.x86_64 gnomad2-0:2.9.6-10.fc21.x86_64 gvfs-mtp-0:1.22.2-1.fc21.x86_64 gvfs-mtp-0:1.22.4-2.fc21.x86_64 kio_mtp-0:0.75-6.20131020git2063e75.fc21.x86_64 kio_mtp-0:0.75-10.20141221gitc418634.fc21.x86_64 libmtp-devel-0:1.1.8-1.fc21.i686 libmtp-devel-0:1.1.8-1.fc21.x86_64 libmtp-devel-0:1.1.9-1.fc21.i686 libmtp-devel-0:1.1.9-1.fc21.x86_64 libmtp-examples-0:1.1.8-1.fc21.x86_64 libmtp-examples-0:1.1.9-1.fc21.x86_64 python-pymtp-0:0.0.6-3.fc21.x86_64 rhythmbox-0:3.1-1.fc21.i686 rhythmbox-0:3.1-1.fc21.x86_64 simple-mtpfs-0:0.2-3.fc21.x86_64 vlc-core-0:2.2.0-0.2.fc21.x86_64 vlc-core-0:2.2.1-5.fc21.i686 vlc-core-0:2.2.1-5.fc21.x86_64 vlc-core-0:2.2.2-0.1.fc21.i686 vlc-core-0:2.2.2-0.1.fc21.x86_64
(In reply to Sergio Monteiro Basto from comment #3) > dnf repoquery --whatrequires is broken on Fedora 21. What does that have to do with this bug report?
it does have bug 1245137, which a dup of this
Sorry my mistake , this reports are for Fedora 22 and 23 , my issue is for Fedora 21 . I opened a new bug #1272638 , last 3 comments can be ignored . Sorry
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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.
This bug has been fixed in DNF 2.0 which will be released soon and pushed to F23+.
I suggest keeping the bug open until it has actually happened, so people will have better awareness and visibility to the issue and what's happening to it.
(In reply to Ville Skyttä from comment #10) > I suggest keeping the bug open until it has actually happened, so people > will have better awareness and visibility to the issue and what's happening > to it. We have more than 500 bugs opened and it's completely not possible to track all of them (thanks bugzilla). So we are trying to close already fixed bugs (we fixed a lot of them in 2.0)
Well, closing bugs without actually having the fix delivered makes it likely that you'll receive even _more_ bugs as people report "duplicates", but meh... have it your way.
(In reply to Ville Skyttä from comment #12) > Well, closing bugs without actually having the fix delivered makes it likely > that you'll receive even _more_ bugs as people report "duplicates", but > meh... have it your way. it wasn't my decision to track all upstream bugs in RHBZ, I prefer to have github issues for upstream bugs and here for tracking, but what can I do.