qfile -o is partly broken as seen on my machine. Ion ~ # qfile --version portage-utils-0.6: compiled on Oct 19 2011 $Id: qfile.c,v 1.58 2011/10/02 22:08:49 vapier Exp $ file written for Gentoo by <solar and vapier @ gentoo.org> Ion ~ # qfile -o /usr/lib64/xorg/modules/extensions/libdri.so /usr/lib64/xorg/modules/extensions/libdri.so Ion ~ # equery b /usr/lib/xorg/modules/extensions/libdri.so * Searching for /usr/lib/xorg/modules/extensions/libdri.so ... x11-base/xorg-server-1.10.4-r1 (/usr/lib64/opengl/xorg-x11/extensions/libdri.so) It is also return false results when dealing with symlinks: Ion ~ # qfile -o /usr/lib/libGL.so /usr/lib/libGL.so Ion ~ # ls -la /usr/lib/libGL.so lrwxrwxrwx 1 root root 32 Окт 19 00:26 /usr/lib/libGL.so -> opengl/xorg-x11/lib/libGL.so.1.2 Ion ~ # equery b /usr/lib/libGL.so * Searching for /usr/lib/libGL.so ... media-libs/mesa-7.11 (/usr/lib64/opengl/xorg-x11/lib/libGL.so.1.2) Ion ~ # qfile -o /usr/lib64/opengl/xorg-x11/lib/libGL.so.1.2 None returned with the last command (as expected). So, qfile -o feature can not be trusted yet also it is not usable. Reproducible: Always
This is expected behavior, qfile -o only checks for files created during the emerge process, not ones generated later by things like eselect-mesa.
the examples you've posted are symlinks not owned by any pkg that i can see. if you look at the equery output, it's telling you what owns the *destination* of the symlink, not the symlink itself. qfile will tell you what owns the symlink. compare & contrast: $ cd /tmp $ ln -s /bin/ls $ qfile -o /tmp/ls /tmp/ls $ equery /tmp/ls * Searching for /tmp/ls ... sys-apps/coreutils-8.14 (/bin/ls)
Thanks for the explanation. It was just my misunderstanding.
i might be open to adding an option so people can say "resolve symlinks, and then tell me what owns the file". not sure though.
(In reply to comment #4) > i might be open to adding an option so people can say "resolve symlinks, and > then tell me what owns the file". not sure though. That would be great!
