Here is a patch which makes qfile more reliable when used with $ROOT!="/". The general case (opening $ROOT/var/db/pkg/... and finding exact matches) was already fine, but the weird ones were not: all "realpath()" calls were done directly under "/", so resolution of paths involving symlinks was wrong (that makes a difference if, for instance, /usr/X11R6 is a symlink to /usr, but ${ROOT}/usr/X11R6 is a real directory). I'm sorry, it's a big diff again, i should have thought of that at bug #130004 time... This patch also adds a new option (-R, --root-prefix) to specify whether or not your arguments include the $ROOT prefix. It means that this two commands are equivalent: # ROOT=/var/tmp/test-root qfile /bin/sh # ROOT=/var/tmp/test-root qfile -R /var/tmp/test-root/bin/sh The first one is the original qfile behavior, and the second one can be convenient too, in particular when arguments come from shell wildcards, or a find command, etc. This option also change qfile output in a similar way. Result of the first command will be "sys-apps/busybox (/bin/sh)" whereas result of the 2nd one will be "sys-apps/busybox (/var/tmp/test-root/bin/sh)". Finally, this patch also includes: - some bugfix for corner cases ("qfile ." was not working, and i'm sure there was an other one that i don't remember) - an optimization which makes big queries ("qfile /usr/bin/*" for instance) almost 50% faster. The idea is to avoid numerous "strcmp()" calls on basenames, by doing first a comparaison of their first chars (stored in an other array and a local variable). I've tried a few other less dumb approachs, with hashes of the full strings, but this one was actually the best compromise i've found (despite it obviously leaves many strcmp() calls, it is also very cheap by itself).
Created attachment 93084 [details, diff] qfile-0.20-better-ROOT-support.patch
The display results I get from this patch are questionable. I don't think this is what you probably expected for behavior. env ROOT=/dev/shm emerge -K portage-utils $ ROOT=/dev/shm ./qfile q app-portage/portage-utils (/usr/bin/q) $ ROOT=/dev/shm ./qfile /dev/shm/usr/bin/q $ ROOT=/dev/shm ./qfile -R /dev/shm /usr/bin/q file: Real path of "/dev/" is not under ROOT: /dev file: Skipping query item "/dev/shm". file: Real path of "/usr/bin/" is not under ROOT: /usr/bin file: Skipping query item "/usr/bin/q". $ ./qfile -R /dev/shm /usr/bin/q app-portage/portage-utils (/usr/bin/q) $ ROOT=/dev/shm ./qfile /usr/bin/q app-portage/portage-utils (/usr/bin/q) $ ROOT=/dev/shm ./qfile -R /dev/shm/ /dev/shm/usr/bin/q file: Real path of "/dev/" is not under ROOT: /dev file: Skipping query item "/dev/shm". app-portage/portage-utils (/dev/shm/usr/bin/q)
(In reply to comment #2) > I don't think this is what you probably expected for behavior. Actually it is: > $ ROOT=/dev/shm ./qfile /dev/shm/usr/bin/q No result because "q" is recorded in VDB as "/usr/bin/q", not "/dev/shm/usr/bin/q". It is also the current qfile behavior. Valid queries would rather be one this two: $ ROOT=/dev/shm ./qfile /usr/bin/q $ ROOT=/dev/shm ./qfile -R /dev/shm/usr/bin/q > $ ROOT=/dev/shm ./qfile -R /dev/shm /usr/bin/q > file: Real path of "/dev/" is not under ROOT: /dev > file: Skipping query item "/dev/shm". > file: Real path of "/usr/bin/" is not under ROOT: /usr/bin > file: Skipping query item "/usr/bin/q". There should be no space in "/dev/shm /usr/bin/q". The -R option expects no parameter: it is a simple flag to say that your query items already include their $ROOT prefix. Its purpose is to be able to do things like this: $ ROOT=/dev/shm ./qfile -R /dev/shm/usr/bin/* ...as a shortcut for: $ ROOT=/dev/shm ./qfile $(ls /dev/shm/usr/bin/ | sed "s:^/dev/shm::") It also allows things like this: $ cd /dev/shm/usr/bin $ ROOT=/dev/shm ./qfile -R ./q I think this explains the other weirdness you've seen (each time, you have 2 query items, where you were thinking of only one).
Since obviously the -R behavior was not obvious, i've thought it should be better documented in the manpage. I will attach a patch which does that (and also details the other options, since i was at it...). The manpage is still generated by help2man, but includes some additional sections (see the mkman.sh change in first chunk of the patch). Do you think it's a good idea?
Created attachment 94694 [details, diff] portage-utils-0.1.20-verbose-qfile-manpage.patch
I merged your patch but shoved all the include files in man/include/*.include
Released in portage-utils-0.1.21
