Hi, I tried running 'equery belongs /usr/X11R6/lib/libaspell.so.<version>'. equery was unable to find out which package this file belongs to. /usr/X11R6 is a symlink to /usr. It appears that equery doesn't use realpath() to support symlinks. Best regards, Stu
Yeah, I always wondered why it does not work for me...
*** Bug 102605 has been marked as a duplicate of this bug. ***
equery wasn't designed to check if the argument that is passed actually exists on the file system. It was designed to take the argument and search the contents of the packages to see what package, if any, contains that argument. Since libaspell.so.<version> wasn't installed in /usr/X11R6/lib, it doesn't find a package. Right now, I don't see a clean and easy way to accomplish what you want based upon the current design of equery.
*** Bug 113708 has been marked as a duplicate of this bug. ***
>equery wasn't designed to check if the argument that is passed actually exists >on the file system I suppose YOU didn't understand the problem, >/usr/X11R6/lib/libaspell.so.<version> <version> is used as indication, not as real example. I try show you facts: fact one: file /usr/X11R6/lib/libaspell.so.15 appera after "emerge aspell" and will disappear after "emerge unmerge aspell", hence it belongs to aspell package fact number two according to "equery b /usr/X11R6/lib/libaspell.so.15", this file doesn't belong to any package, this is BUG. solution is simple: equery b `readlink -f /usr/lib/libaspell.so.15.0.3` BUT it is too boring every time check if some file is symbolic link or not and use readlink, so can you before handle arguments use "readlink -f" or some similar stuff?
(In reply to comment #5) > >equery wasn't designed to check if the argument that is passed actually exists > >on the file system > > I suppose YOU didn't understand the problem, Incorrect. You just don't understand the implications of the problem. > I try show you facts: > fact one: > file /usr/X11R6/lib/libaspell.so.15 appera after "emerge aspell" and will disappear > after "emerge unmerge aspell", > hence it belongs to aspell package Wrong. There is no such file. > fact number two > according to "equery b /usr/X11R6/lib/libaspell.so.15", > this file doesn't belong to any package, > this is BUG. It's not. It's a semantic screwup by xorg (unfortunately needed for compability). > solution is simple: > > equery b `readlink -f /usr/lib/libaspell.so.15.0.3` That's completely unrelated to your example above. Also I guess you're mixing up "solution" and "workaround". > BUT it is too boring every time check if some file is symbolic link or not and > use readlink, > > so can you before handle arguments use "readlink -f" or some similar stuff? a) in your example the file being a symlink isn't the problem, it's the crappy X11R6 symlink b) using realpath (or something equivalent) unconditionally would generate wrong results, so not an option c) IMO `equery belongs` should match `equery files` which implicates that symlinks shouldn't be resolved So all in all if this gets implemented it should be an off-by-default option.
I think that from a "logic" point of view Marius is right. If a package installs a symlink, it should be shown by equery belongs as well as by equery files (and I strongly assume that it does). If you can access a file thought a symlink from another package, then that path to the file is clearly should not be printed by equery files, and if you give priority to consistency between equery files and equery belongs then neither should equery belongs recognize it. However, I do not think we should give priority to consistency over userfriendlyness unless consistency servers a higher purpose than consistency itself ("A foolish consistency is the hobgoblin of little minds", but who can say if a consistency is foolish?). In this case, I think the typical use of "equery belongs" is to identify which package is to blame for a problem with a file. In that case, it is useful to get a reply from equery belongs, even if it is not 100% consistent with equery files. Implementing it as a per-default off option is not going to help, because if the user realizes he has to turn on the option he has probably already solved his problem. I suggest that if "equery belongs" fails to find a file, it tries again with the readlink trick, and then prints a warning along with the result: # equery belongs /usr/lib/libgle.so.3.0.0 [ Searching for file(s) /usr/lib/libgle.so.3.0.0 in *... ] media-libs/gle-3.0.1-r2 (/usr/lib/libgle.so.3.0.0) # equery belongs /usr/X11R6/lib/libgle.so.3.0.0 [ Searching for file(s) /usr/X11R6/lib/libgle.so.3.0.0 in *... ] media-libs/gle-3.0.1-r2 (/usr/lib/libgle.so.3.0.0 - ACCESSED THROUGH SYMBOLIC LINK) /Jakob
Created attachment 73718 [details, diff] equery-b-symlinks.patch This patch allows equery b to work with symlink directories. Unlike the readlink -f workaround/hack, this should work regardless of whether the ebuild installed the file through a symlink or through the actual directory name. It has its problems - previously supported functionality is removed (notably equery b -f). Also, it only handles symlink directories; symlink files such as #113708 (/usr/bin/gprof -> i686-pc-linux-gnu-gprof -> ../i686-pc-linux-gnu/bin/gprof) are not handled. (Personally, since /usr/bin/gprof is not created by an ebuild, I don't think it should be shown, and since /usr/X11R6/<...> is (with a different name, but it is the exact same file), I think it should.) This patch is intended mainly as an idea of how this could be handled, not as the actual solution. $ gentoolkit-0.2.1_rc2/src/equery/equery b /usr/X11R6/X11R6 [ Searching for file(s) /usr/X11R6/X11R6 in *... ] x11-base/xorg-x11-6.8.2-r6 (/usr/X11R6)
*** Bug 134719 has been marked as a duplicate of this bug. ***
*** Bug 195083 has been marked as a duplicate of this bug. ***
What's the word on this bug? The /usr/X11R6 example is pretty outdated. If someone can provide a modern example and justification for it, I'll work on doing this right. Otherwise, let's close it.
The more modern example is the /usr/lib symlink to /usr/lib64 on the amd64 architecture. On my amd64 box: # equery belongs /usr/lib | cat | wc -l 13 # equery belongs /usr/lib64 | cat | wc -l 461 All of the files actually reside in /usr/lib64, however for 13 packages in my system they were installed into /usr/lib So for this to work, we need to be able to check both the symlinked path and the real path regardless of which path name was given as the argument.
*** Bug 286508 has been marked as a duplicate of this bug. ***
This was fixed a short time back. Reopen if you disagree.
Can you say in which version of gentoolkit it has been fixed? With the current stable version, 0.2.4.5, I have the same problems.
(In reply to comment #15) > Can you say in which version of gentoolkit it has been fixed? With the current > stable version, 0.2.4.5, I have the same problems. > Latest unstable contains the fix... gentoolkit-0.3.0_rc9. The 0.2* branch is still actively maintained, but really only bugfixes are being backported. For new features and enhancements (and there are a lot) use the 0.3.0 branch.
*** Bug 361259 has been marked as a duplicate of this bug. ***
Broken again in the lastest version: $ equery belongs /usr/lib/libedata-book-1.2.so.8.0.0 * Searching for /usr/lib/libedata-book-1.2.so.8.0.0 ... $ equery belongs /usr/lib64/libedata-book-1.2.so.8.0.0 * Searching for /usr/lib64/libedata-book-1.2.so.8.0.0 ... gnome-extra/evolution-data-server-2.32.2 (/usr/lib64/libedata-book-1.2.so.8.0.0)
Try out my patch from bug #361259
Created attachment 268039 [details, diff] better-symlink-resolution
Fix committed. http://git.overlays.gentoo.org/gitweb/?p=proj/gentoolkit.git;a=commit;h=eb134645c0bc8938a87a076c386c37571b61fc00
Released in gentoolkit-0.3.0
