After a merge-usr /bin, /sbin, /lib and /lib64 are now symlinks - fine ie. sys-apps/iproute2 installs into /bin (meaning files end up in /usr/bin as expected) ns ~ # which ip /usr/bin/ip But equery doesn't know the owner ns ~ # equery b /usr/bin/ip * Searching for /usr/bin/ip ... Reproducible: Always Steps to Reproduce: 1. switch to merge-usr 2. try to equery files which ebuilds install into /bin, /sbin, /lib, /lib64 3. Not sure if it's gentoolkit that needs an update of some sort - or it's all the ebuilds installing into the symlinked paths?
Meanwhile, you can use portageq which has no issue with usrmerge: # portageq owners / /usr/bin/ip sys-apps/iproute2-6.6.0-r3 /bin/ip None of the installed packages claim these files: /usr/bin/ip
Unfortunately the equery belongs -f, --full-regex option can't really handle this since it operates on strings, but when regex mode is disabled we could use portage APIs to determine true owners like portageq owners does.
@(In reply to Zac Medico from comment #2) > Unfortunately the equery belongs -f, --full-regex option can't really handle > this since it operates on strings, but when regex mode is disabled we could > use portage APIs to determine true owners like portageq owners does. How does portageq resolve this? I'm asking since app-portage/pfl does have the same lookup problem https://github.com/portagefilelist/client/issues/55 pfl does use portage.db[eroot]['vartree'].dbapi from the portage python package. https://dev.gentoo.org/~zmedico/portage/doc/api/
Crap. Comment #3 is aimed at #1
In reply to https://bugs.gentoo.org/927640#c3 Are you sure app-portage/pfl doesn't have same problem as equery? It was this thread that triggered me to try equery as I didn't know pfl - https://forums.gentoo.org/viewtopic-t-1168013.html For me pfl/e-file found nothing when querying /usr/bin/ip - only when querying /bin/ip.
(In reply to Kim B. Sindalsen from comment #5) > In reply to https://bugs.gentoo.org/927640#c3 > > Are you sure app-portage/pfl doesn't have same problem as equery? > > It was this thread that triggered me to try equery as I didn't know pfl - > https://forums.gentoo.org/viewtopic-t-1168013.html > > For me pfl/e-file found nothing when querying /usr/bin/ip - only when > querying /bin/ip. Yeah, that is the same behavior. pfl also only knows /bin/ip and not /usr/bin/ip and I think equery and pfl/e-file do operate on the same information.
(In reply to Zac Medico from comment #2) > Unfortunately the equery belongs -f, --full-regex option can't really handle > this since it operates on strings, but when regex mode is disabled we could > use portage APIs to determine true owners like portageq owners does. Unfortunately pfl will have a similar problem, since it uses string matching (portageq owners maps strings to inodes on disk and then back to strings again).
I've not tested it yet, but in an old thread I've found that rebuilding should help... https://forums.gentoo.org/viewtopic-t-1163558-highlight-.html > Eventually, this is solved naturally by updating. However, you can force rebuilding of everything using emerge -1av /bin /sbin if this important to get done now.
(In reply to Banana from comment #8) > I've not tested it yet, but in an old thread I've found that rebuilding > should help... > https://forums.gentoo.org/viewtopic-t-1163558-highlight-.html > > > Eventually, this is solved naturally by updating. However, you can force rebuilding of everything using emerge -1av /bin /sbin if this important to get done now. Well I already rebuilt sys-apps/iproute2-6.6.0-r3 and equery belongs still doesn't work for /usr/bin/ip: # equery belongs /usr/bin/ip * Searching for /usr/bin/ip ... # equery belongs /bin/ip * Searching for /bin/ip ... sys-apps/iproute2-6.6.0-r3 (/bin/ip) If you look in /var/db/pkg/sys-apps/iproute2-6.6.0-r3/CONTENTS you'll see it refers to /bin/ip so that's why /usr/bin/ip does not return a match.
(In reply to Zac Medico from comment #9) > (In reply to Banana from comment #8) > > I've not tested it yet, but in an old thread I've found that rebuilding > > should help... > > https://forums.gentoo.org/viewtopic-t-1163558-highlight-.html > > > > > Eventually, this is solved naturally by updating. However, you can force rebuilding of everything using emerge -1av /bin /sbin if this important to get done now. > > Well I already rebuilt sys-apps/iproute2-6.6.0-r3 and equery belongs still > doesn't work for /usr/bin/ip: > > # equery belongs /usr/bin/ip > * Searching for /usr/bin/ip ... > # equery belongs /bin/ip > * Searching for /bin/ip ... > sys-apps/iproute2-6.6.0-r3 (/bin/ip) > > If you look in /var/db/pkg/sys-apps/iproute2-6.6.0-r3/CONTENTS you'll see it > refers to /bin/ip so that's why /usr/bin/ip does not return a match. Thx for the confirmation! I still don't understand how portageq resolve this? I could implement some logic into pfl/e-file to work around this, but I'm not sure if I mess things up.
As of now, I've implemented some alias logic into the search for e-file and the webinterface at portagefilelist.de A search for /usr/bin/bash with e-file results in app-shells/bash Seen Versions: 5.1_p16-r6 5.1_p16-r7 5.1_p8 5.2_p15-r6 5.2_p21 5.2_p21-r1 5.2_p21-r2 5.2_p26 Portage Versions: 2.05b_p13 3.0_p22 3.1_p23 3.2_p57 4.0_p44 4.1_p17 4.2_p53 4.3_p48-r2 4.4_p23-r2 5.0_p18-r2 5.1_p16-r6 5.1_p16-r7 5.2_p26 9999 Repository: gentoo Installed Versions: 5.1_p16-r6(Sat Mar 23 10:07:13 2024) Homepage: https://tiswww.case.edu/php/chet/bash/bashtop.html https://git.savannah.gnu.org/cgit/bash.git Description: The standard GNU Bourne again shell Matched Files: /bin/bash and also here: https://www.portagefilelist.de/index.php?fs=%2Fusr%2Fbin%2Fbash#panchor This is the same as for /bin/bash
(In reply to Banana from comment #8) > I've not tested it yet, but in an old thread I've found that rebuilding > should help... > https://forums.gentoo.org/viewtopic-t-1163558-highlight-.html > > > Eventually, this is solved naturally by updating. However, you can force rebuilding of everything using emerge -1av /bin /sbin if this important to get done now. There's no way rebuild will help. The issue is explained here: https://forums.gentoo.org/viewtopic-p-8821486.html#8821486 and it has no proper solution. The workaround is not to use fully qualified paths, just file names. Equery will still find the file in the database that way. Best Regards, Georgi
(In reply to Banana from comment #10) > Thx for the confirmation! I still don't understand how portageq resolve this? portageq uses stat to get the inode of the parent directory, which gives it a path-independent way to refer to it. Then it maps this inode back to one of the directories listed in CONTENTS, this way it can find the directory in CONTENTS that corresponds to /usr/bin. This kind of inode usage started long ago, with bug 80846: https://gitweb.gentoo.org/proj/portage.git/commit/?id=3ba3548665d60542ae6b8cd856240f55f3ed58ad > I could implement some logic into pfl/e-file to work around this, but I'm > not sure if I mess things up. I imagine that since you may not have access to inodes it's probably easiest to just assume that you have a merge-usr system with the symlinks specified here: https://github.com/floppym/merge-usr/blob/master/merge-usr#L17 (In reply to Georgi from comment #12) > The workaround is not to use fully qualified paths, just file names. Equery > will still find the file in the database that way. Maybe it's nicer to not throw out fully qualified paths and instead map them using the merge-usr symlinks defined here: https://github.com/floppym/merge-usr/blob/master/merge-usr#L17
(In reply to Zac Medico from comment #13) > (In reply to Banana from comment #10) > > Thx for the confirmation! I still don't understand how portageq resolve this? > > portageq uses stat to get the inode of the parent directory, which gives it > a path-independent way to refer to it. Then it maps this inode back to one > of the directories listed in CONTENTS, this way it can find the directory in > CONTENTS that corresponds to /usr/bin. This kind of inode usage started long > ago, with bug 80846: > > https://gitweb.gentoo.org/proj/portage.git/commit/?id=3ba3548665d60542ae6b8cd856240f55f3ed58ad Initially it gathered stat results for every inode, but then it was optimized to only gather them for parent directories in this commit: https://gitweb.gentoo.org/proj/portage.git/commit/?id=20df5faa51753aae84791277cd0d07c6b44114bf
