Created attachment 1387880 [details]
partial edited log of my bash session
Description of problem:
dnf repoquery --requires --resolve takes an unexpectedly long time to execute for some packages.
Version-Release number of selected component (if applicable):
$ dnf --version
Installed: dnf-0:2.7.5-2.fc27.noarch at Mon 29 Jan 2018 08:13:24 AM GMT
Built : Fedora Project at Wed 29 Nov 2017 09:48:50 AM GMT
Installed: rpm-0:4.14.0-2.fc27.x86_64 at Mon 29 Jan 2018 08:11:23 AM GMT
Built : Fedora Project at Thu 12 Oct 2017 02:18:15 PM GMT
Depending on the package you want to resolve the requirements for the execution time varies: it takes more than 25 minutes for libreoffice-writer, about 15 minutes for firefox but for bash it only takes 15 seconds.
Steps to Reproduce:
1. run: time dnf repoqery libreoffice-writer --requires --resolve
2. compare to: time dnf repoqery libreoffice-writer --requires --tree
The --resolve variation took more than 27 minutes while the --tree variation took about 15 seconds.
$ time dnf repoquery libreoffice-writer --requires --tree > ~/tree.txt
Last metadata expiration check: 0:05:53 ago on Mon 29 Jan 2018 05:35:01 PM MSK.
$ time dnf repoquery libreoffice-writer --requires --resolve > ~/pkg.txt
Last metadata expiration check: 0:07:02 ago on Mon 29 Jan 2018 05:35:01 PM MSK.
I would expect --resolve to take at most as much as --tree because --tree reports all the information --resolve does and then some.
It looks like this issue was fixed in 2016 https://bugzilla.redhat.com/show_bug.cgi?id=1279538 but now it seams to have returned.
This happened to me too with the same dnf version. Also, using the --installed flag seems to solve it.
Inside the RepoQueryCommand class, the problem seems to be here:
if self.opts.list == "installed":
query = self.filter_repo_arch(self.opts, self.base.sack.query())
query = self.filter_repo_arch(self.opts, self.base.sack.query().available())
I don't know why using available() makes things so slow.
Possible duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1279538
BTW, the issue is marked as solved but not, might be a regression
PR mentioned in comment 2 is not merged into upstream yet. If you want to test it, you can update dnf from my testing copr repository https://copr.fedorainfracloud.org/coprs/mblaha/dnf/
# dnf copr enable mblaha/dnf
# dnf update dnf
# time dnf repoquery -Cq --requires --resolve wine-core-0:3.4-1.fc27.x86_64
Regarding the solved bug 1279538, this bug was filed against dnf version 1. But solution is very similar - not using glob when not necessary.
I can confirm that your PR solves the issue.
The issue is solved by dnf-3.0.1-1 that was released into rawhide.