Example: qdepends --depend dev-libs/beecrypt dev-libs/beecrypt-4.2.1-r4: !<app-arch/rpm-4.2.1 >=dev-libs/icu-2.8:0/58.1= !<sys-devel/gettext-0.18.1.1-r3 >=sys-devel/automake-1.15:1.15 >=sys-devel/autoconf-2.69 >=sys-devel/libtool-2.4 qdepends --depend -Q dev-libs/icu media-sound/mpd-0.19.21 dev-libs/beecrypt-4.2.1-r4 app-text/texlive-core-2015-r1 dev-qt/qtcore-4.8.7-r2 dev-qt/qtcore-5.7.1-r1 dev-qt/qtwebkit-4.8.7 dev-qt/qtwebkit-5.7.1 dev-lang/spidermonkey-24.2.0-r3 app-misc/tracker-1.8.0 media-libs/harfbuzz-1.4.2 net-libs/webkit-gtk-2.4.11-r200 dev-tex/bibtexu-3.71_p20160523 qdepends --depend -Q dev-libs/icu:0/58.1= <no output> qdepends --depend -Q dev-libs/icu:0/58.1 <no output> qdepends --depend -Q dev-libs/icu:0 media-sound/mpd-0.19.21 dev-qt/qtcore-4.8.7-r2 dev-qt/qtcore-5.7.1-r1 dev-qt/qtwebkit-4.8.7 dev-qt/qtwebkit-5.7.1 Reading some other bugs I get the impression "Q" is a *regex*, which is not what I assumed it was, ( and there wasn't any documentation leading me to other conclusions ). But this makes it kinda un-useful and secretly dangerous if relied upon. Because it gives *seemingly* right responses often enough to think it works as expected, while secretly omitting relevant results that should be returned. I'm not sure whether or not this constitutes an enhancement request though. ( Making existing behaviour more obvious to a consumer would probably be a good start ) Sadly, equery seems to be the only thing close to what I mean, and its interface is slightly less favourable for plumbing tools. You could possibly use a regex approach for a "candidate list" ( ie: searching for atoms quickly that match a simplified substring ), and then post-validating/filtering them with full portage rules.
And gross, eq
And gross, equery d is useless for other reasons: equery d "dev-lang/perl:0/5.22=" ^ returns everything that depends on "dev-lang/perl" regardless of slot.
qdepends -Q <pkgname> provides a misleading result. The manual page should clarify the result or better the software (applet?) should be modified. In my opinion, the manual (the pages of the Q applets) is not precise enough. We can not use the applications properly unless we have prior knowledge. Normally, the command qdepends -Q <pkgname-version> should provide all the installed reverse dependencies related to "this version". In fact, qdepends -Q is not reliable when specifying a version number with the package name. It seems that the algorithm used is not correct. * [Example] # net-misc/curl-7.54.1 (installed version on my system) (chroot) larry / # qdepends -Q net-misc/curl-7.54.1 # -> no answer for this query (chroot) larry / # qdepends -Q net-misc/curl app-crypt/gnupg-2.1.20-r1 dev-vcs/git-2.13.0 app-text/mupdf-1.11-r1 dev-util/cmake-3.7.2 # Look at the ebuilds: # gnupg-2.1.20-r1.ebuild [l.25]: >=net-misc/curl-7.10 # git-2.13.5.ebuild [l.58]: net-misc/curl # (git-2.13.0 is no longer available) # mupdf-1.11-r1.ebuild [l.26]: net-misc/curl[static-libs?] # cmake-3.7.2.ebuild [l.26]: >=net-misc/curl-7.21.5[ssl] (chroot) larry / # qdepends -Q net-misc/curl-7.10 app-crypt/gnupg-2.1.20-r1 (chroot) larry / # qdepends -Q net-misc/curl-7.21.5 dev-util/cmake-3.7.2
(In reply to Kent Fredric (IRC: kent\n) from comment #0) > You could possibly use a regex approach for a "candidate list" ( ie: > searching for atoms quickly that match a simplified substring ), and then > post-validating/filtering them with full portage rules. This is my plan at the moment, if there is a match, parse both into atoms and compare that way.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage-utils.git/commit/?id=3d00cad113975b02ece79892eb5f752d818aaa73 commit 3d00cad113975b02ece79892eb5f752d818aaa73 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2018-03-25 13:57:56 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2018-03-25 13:57:56 +0000 qdepends_vdb_deep_cb: use atom matching when possible, bug #608960 When the argument is an atom-parsable thing, match whatever we find in the vdb as atom, such that version and range can be taken into account. Bug: https://bugs.gentoo.org/608960 qdepends.c | 118 +++++++++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 95 insertions(+), 23 deletions(-)}
*** Bug 645560 has been marked as a duplicate of this bug. ***
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=34b636503cc7dcabe32b9b377c2eb77cb5fd5575 commit 34b636503cc7dcabe32b9b377c2eb77cb5fd5575 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2018-04-05 19:02:10 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2018-04-05 19:02:34 +0000 app-portage/portage-utils: version bump to 0.70 This release fixes multiple bugs lingering around for a while. Closes: https://bugs.gentoo.org/651546 Closes: https://bugs.gentoo.org/646310 Closes: https://bugs.gentoo.org/645554 Closes: https://bugs.gentoo.org/643820 Closes: https://bugs.gentoo.org/638032 Closes: https://bugs.gentoo.org/608960 Closes: https://bugs.gentoo.org/607498 Closes: https://bugs.gentoo.org/558306 Closes: https://bugs.gentoo.org/526596 Closes: https://bugs.gentoo.org/470168 Closes: https://bugs.gentoo.org/351100 Closes: https://bugs.gentoo.org/335453 Package-Manager: Portage-2.3.24, Repoman-2.3.6 app-portage/portage-utils/Manifest | 2 +- .../portage-utils/portage-utils-0.62.ebuild | 2 +- .../portage-utils/portage-utils-0.63.ebuild | 43 ---------------------- ...ls-0.64-r1.ebuild => portage-utils-0.70.ebuild} | 16 +------- 4 files changed, 4 insertions(+), 59 deletions(-)
