It's seems qsearch does not look at the other repos for basic search. Looking at the strace trace, every repos.conf is successfully parsed; but search is only performed into gentoo repos only. The same behaviour is observed with a single repos.conf instead of a directory. And it looks like the search is performed in the tree instead of the metadata? Thanks! Reproducible: Always
Created attachment 405758 [details] strace qsearch -v media-sound/ladish The package is available in bar-overlay but still not found as any package not found in the main tree.
Almost forgot... could qsearch include at least the homepage and version available? It's off topic but I don't know any place to ask this, issue tracker if disabled.
qsearch has only ever parsed the *main* repo (e.g. PORTDIR). no q util hardcodes the "gentoo" repo anywhere.
(In reply to SpanKY from comment #3) > qsearch has only ever parsed the *main* repo (e.g. PORTDIR). no q util > hardcodes the "gentoo" repo anywhere. The repos.conf parsing should be used to something usefull... although I have no idea on the difficulty to loop the repos when searching a package. Is that that difficult to do? What's about the metadata usage to speed up thing if available instead of parsing every CAT/PKG? Thanks.
(In reply to tokiclover from comment #4) it is being used for something useful as i described: we look up the main repo that is listed there assuming it's the main tree (which has all the normal metadata files). if you change the main-repo setting to point somewhere else, that will be used instead.
(In reply to SpanKY from comment #5) > (In reply to tokiclover from comment #4) > > it is being used for something useful as i described: we look up the main > repo that is listed there assuming it's the main tree (which has all the > normal metadata files). if you change the main-repo setting to point > somewhere else, that will be used instead. I was assuming this after your previous comment, so, this is a confirmation of that assumption. Still, *any* user who does not not know this *internal* behaviour would be left in the cold expecting some positive results as... completely *negative* because it does not ring a bell--even if anyone ring one to enter somewhere--to choose a repos for searching. Well then, if this is the desired and intended default... please add a short line in the man(1) page then. So, other users won't be surprised by this. Thanks. NOTE: * This bug can be closed then (as won't fix?) * Second one note is: I was talking about reading *all* the particular *repos.conf* in case there were many, or, the whole repository list in case of a single file. Having that list of repository could be used to good usage instead of limiting the scope to a single repository.
(In reply to tokiclover from comment #6) i don't see why you find this behavior surprising. it is behaving as it always has, and it behaves the same way that all Gentoo tools have: the main repo is exactly that: the main repo. in the past it was called PORTDIR, but now it is set up via repos.conf. this is not "internal" behavior at all. the fact that qsearch (and other portage-utils) have only ever searched the main repo is also not new -- we didn't support PORTDIR_OVERLAYS in the past, and we don't support the non-main repos listed in repos.conf tody. the request never came up so it wasn't implemented. the bug is still open because at some point, support will be added to walk all repos and not just the main one.
i've landed a number of updates, but most are just laying ground work. only `quse -D` and `qpkg` support multiple overlays properly now. http://gitweb.gentoo.org/proj/portage-utils.git/commit/?id=6c23cea972914761a0b1d4c79326da9f0352e758 http://gitweb.gentoo.org/proj/portage-utils.git/commit/?id=c59331531a36c9d3a9e56aca35e5a71760c73c93 http://gitweb.gentoo.org/proj/portage-utils.git/commit/?id=cb952155e5a9b5d3af533a9d46c561fee47c22f9 http://gitweb.gentoo.org/proj/portage-utils.git/commit/?id=dab9ae7d90f2b51f2d1abb4700b025c14ab77ef5 qgrep, qsearch, and quse will require refactoring of their main funcs in order to make adding overlay support to them more sane.
here's the rest which will be in the next release http://gitweb.gentoo.org/proj/portage-utils.git/commit/?id=9ff62a4efd3cc34e852c55b3c52441a2a481d7cf http://gitweb.gentoo.org/proj/portage-utils.git/commit/?id=f162c6a9219deacfe23c8e21b732f8594a938130 http://gitweb.gentoo.org/proj/portage-utils.git/commit/?id=89d451252b18c0ae2f768f6248964638f8aadd9f http://gitweb.gentoo.org/proj/portage-utils.git/commit/?id=a0c3ddab026e271b3eb2e66e64b9e9a24eb6f708 http://gitweb.gentoo.org/proj/portage-utils.git/commit/?id=48aac66f8c73c63926868317f9a47d5582d5bbd5
I don't think this bug is fixed. Can anybody really get results from overlay? I don't think so. Because there is an obvious typo bug in function read_repos_conf() in main.c. The following is my patch against the bug. Please take a look. As I said, it's an obvious bug. diff -ru portage-utils-0.63.old/main.c portage-utils-0.63/main.c --- portage-utils-0.63.old/main.c 2016-03-27 20:53:50.000000000 -0700 +++ portage-utils-0.63/main.c 2016-09-11 21:20:44.000000000 -0700 @@ -507,7 +507,7 @@ #endif { struct stat st; - if (stat(sub_conf, &st) || S_ISREG(st.st_mode)) + if (stat(sub_conf, &st) || !S_ISREG(st.st_mode)) continue; }
(In reply to kouyu from comment #10) please file new bugs rather than tacking onto old closed ones
(In reply to SpanKY from comment #11) that said, that bug was reported & fixed back in April: https://gitweb.gentoo.org/proj/portage-utils.git/commit/?id=7c64d59b55c1681a022f7b774590f512d35782c2
