Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 622156 - app-portage/gentoolkit-0.3.3: equery b does not work when using symlinks
Summary: app-portage/gentoolkit-0.3.3: equery b does not work when using symlinks
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage Tools Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-18 18:39 UTC by Harald Weiner
Modified: 2017-06-27 05:36 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
output of emerge --info (emerge-info.log,8.20 KB, text/plain)
2017-06-18 18:41 UTC, Harald Weiner
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Weiner 2017-06-18 18:39:58 UTC
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
Comment 1 Harald Weiner 2017-06-18 18:41:16 UTC
Created attachment 477150 [details]
output of emerge --info
Comment 2 Paul Varner (RETIRED) gentoo-dev 2017-06-26 15:48:26 UTC
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.
Comment 3 Harald Weiner 2017-06-26 21:56:36 UTC
@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.
Comment 4 Harald Weiner 2017-06-26 22:03:27 UTC
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.
Comment 5 Paul Varner (RETIRED) gentoo-dev 2017-06-27 02:38:06 UTC
(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.
Comment 6 Brian Dolbec gentoo-dev 2017-06-27 05:36:09 UTC
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.