Bug 392025

Summary:	app-portage/portage-utils: qlist -o doesn't work properly
Product:	Portage Development	Reporter:	Coacher <itumaykin+gentoo>
Component:	Tools	Assignee:	Portage Utils Team <portage-utils>
Status:	RESOLVED INVALID
Severity:	normal	CC:	bkohler
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description Coacher 2011-11-26 22:24:14 UTC

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

Comment 1 Ben Kohler gentoo-dev

2011-11-26 22:49:29 UTC

This is expected behavior, qfile -o only checks for files created during the emerge process, not ones generated later by things like eselect-mesa.

Comment 2 SpanKY gentoo-dev

2011-11-27 03:47:49 UTC

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)

Comment 3 Coacher 2011-11-29 07:57:14 UTC

Thanks for the explanation. It was just my misunderstanding.

Comment 4 SpanKY gentoo-dev

2011-12-01 00:31:46 UTC

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.

Comment 5 Coacher 2011-12-01 09:07:12 UTC

(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!