equery belongs does not show a package name for the real files when they are installed over symlinks. Steps to reproduce: 1.) ls -l /usr/lib lrwxrwxrwx 1 root root 5 Oct 30 2014 /usr/lib -> lib64 2.) equery b /usr/lib/clang/3.9.1/lib/linux/libclang_rt.asan-i386.so * Searching for /usr/lib/clang/3.9.1/lib/linux/libclang_rt.asan-i386.so ... sys-devel/llvm-3.9.1-r1 (/usr/lib/clang/3.9.1/lib/linux/libclang_rt.asan-i386.so) 3.) equery b /usr/lib64/clang/3.9.1/lib/linux/libclang_rt.asan-i386.so * Searching for /usr/lib64/clang/3.9.1/lib/linux/libclang_rt.asan-i386.so ... Actual results: Step #3 does not show the right package (the one from step #2). Expected results: Outputs for step #2 and step #3 are identical. Might be related to https://bugs.gentoo.org/show_bug.cgi?id=280341
Created attachment 477150 [details] output of emerge --info
Basically this is because the path that is recorded by portage is /usr/lib and not /usr/lib64 We can probably implement something similar to what portageq does in the same situation $ portageq owners / /usr/lib64/llvm/4/lib64/libLLVMAMDGPUAsmParser.so.4.0.0 sys-devel/llvm-4.0.0-r2 /usr/lib/llvm/4/lib64/libLLVMAMDGPUAsmParser.so.4.0.0 None of the installed packages claim these files: /usr/lib64/llvm/4/lib64/libLLVMAMDGPUAsmParser.so.4.0.0 It shows the package with the correct /usr/lib path, but also states that the /usr/lib64 path is not claimed by the package.
@Paul: Yes, that would be quite nice. It clearly indicates which package the file belongs to while at the same time reminding the user that /usr/lib is the original installation path of the file.
BTW: Are revdep-rebuild and equery somehow related? Because then other bug reports like https://bugs.gentoo.org/show_bug.cgi?id=389647 might be related too.
(In reply to Harald Weiner from comment #4) > BTW: Are revdep-rebuild and equery somehow related? > Because then other bug reports like > https://bugs.gentoo.org/show_bug.cgi?id=389647 might be related too. They are related in that the underlying cause is the same.
Yes, they are related. All part of the same gentoolkit package and both use portage APIs. But no, they do not share the same codebase. And there is code in redep-rebuild that should be taking care of the /usr/lib symlink. That bug is about other arbitrary symlinks.
