Bug 361259 – app-portage/gentoolkit-0.2.4.6.1-r1: `equery belongs' does not correctly follow symbolic links when looking for files that belongs to a package

• Status: RESOLVED DUPLICATE of bug 96515
• Product: Gentoo Linux

[Description Alex Buell 2011-03-30 09:56:21 UTC]

# ls -lt /usr/lib/libedata-book-1.2.so*
lrwxrwxrwx 1 root root     26 Mar 28 20:08 /usr/lib/libedata-book-1.2.so.8 -> libedata-book-1.2.so.8.0.0
lrwxrwxrwx 1 root root     26 Mar 28 20:08 /usr/lib/libedata-book-1.2.so -> libedata-book-1.2.so.8.0.0
-rwxr-xr-x 1 root root 104512 Mar 28 20:08 /usr/lib/libedata-book-1.2.so.2
-rwxr-xr-x 1 root root 180732 Mar 28 20:07 /usr/lib/libedata-book-1.2.so.8.0.0

# equery b /usr/lib/libedata-book-1.2.so.8.0.0 
[ Searching for file(s) /usr/lib/libedata-book-1.2.so.8.0.0 in *... ]

# equery b /usr/lib32/libedata-book-1.2.so.8.0.0 
[ Searching for file(s) /usr/lib32/libedata-book-1.2.so.8.0.0 in *... ]
gnome-extra/evolution-data-server-2.32.2 (/usr/lib32/libedata-book-1.2.so.8.0.0)

# equery b /usr/lib32/libedata-book-1.2.so.2
[ Searching for file(s) /usr/lib32/libedata-book-1.2.so.2 in *... ]
gnome-extra/evolution-data-server-2.32.2 (/usr/lib32/libedata-book-1.2.so.2)

# qfile /usr/lib/libedata-book-1.2.so.8.0.0 
gnome-extra/evolution-data-server (/usr/lib32/libedata-book-1.2.so.8.0.0)

As you can see, qfile works correctly, but equery b clearly does not.

[Comment 1 Vikraman (RETIRED) 2011-03-30 21:20:57 UTC]

% l /lib/libc.so.6 
lrwxrwxrwx 1 root root 14 Mar 12 10:01 /lib/libc.so.6 -> libc-2.11.2.so*

% equery belongs /lib/libc.so.6; equery belongs /lib/libc-2.11.2.so 
 * Searching for /lib/libc.so.6 ... 
sys-libs/glibc-2.11.2-r2 (/lib64/libc-2.11.2.so)
 * Searching for /lib/libc-2.11.2.so ... 

% equery belongs /lib64/libc.so.6; equery belongs /lib64/libc-2.11.2.so 
 * Searching for /lib64/libc.so.6 ... 
sys-libs/glibc-2.11.2-r2 (/lib64/libc.so.6 -> libc-2.11.2.so)
sys-libs/glibc-2.11.2-r2 (/lib64/libc-2.11.2.so)
 * Searching for /lib64/libc-2.11.2.so ... 
sys-libs/glibc-2.11.2-r2 (/lib64/libc-2.11.2.so)

% qfile /lib/libc.so.6; qfile /lib/libc-2.11.2.so 
sys-libs/glibc (/lib64/libc.so.6)
sys-libs/glibc (/lib64/libc-2.11.2.so)

% qfile /lib64/libc.so.6; qfile /lib64/libc-2.11.2.so 
sys-libs/glibc (/lib64/libc.so.6)
sys-libs/glibc (/lib64/libc-2.11.2.so)

[Comment 2 Alex Buell 2011-03-30 22:04:01 UTC]

I forgot to add that this was on SPARC. Which architecture is yours, Vikraman?

[Comment 3 Vikraman (RETIRED) 2011-03-30 22:39:24 UTC]

(In reply to comment #2)
> I forgot to add that this was on SPARC. Which architecture is yours, Vikraman?
AMD64

[Comment 4 Vikraman (RETIRED) 2011-03-30 22:42:58 UTC]

Created attachment 267923 [details, diff]
better-symlink-resolution

I think I figured it out, equery resolves symlinks only at the lowest level, ie, /lib/libc-2.11.2.so is not resolved to /lib64/libc-2.11.2.so, since libc-2.11.2.so is not a symlink. It must have slipped the mind of the authors. Here's a very simple patch to fix it (os.path.realpath already does that).

[Comment 5 Vikraman (RETIRED) 2011-03-30 22:44:22 UTC]

My app-portage/gentoolkit version is 0.3.0_rc11-r3, and IMO this would affect all architectures.

[Comment 6 Paul Varner (RETIRED) 2011-03-31 21:34:04 UTC]

*** This bug has been marked as a duplicate of bug 96515 ***

[Comment 7 Vikraman (RETIRED) 2011-03-31 21:41:59 UTC]

Created attachment 268037 [details, diff]
better-symlink-resolution