qfile use broken by merge-usr

[Frautoincnam]

A while back, I followed the procedure at https://wiki.gentoo.org/wiki/Merge-usr[b][/b], which created the following symbolic links:

Code: Select all

/usr/sbin -> /bin
/bin -> /usr/bin
/sbin -> /usr/bin
/lib -> /usr/lib
/lib64 -> /usr/lib64

I never had any problems with it, except for one major drawback: the qfile tool in app-portage/portage-utils is completely broken.

For example: iproute2 installs the ip binary in /bin. rkhunter finds the modified /usr/bin/ip binary and reports it to me. To see which package this binary belongs to, I run qfile /usr/bin/ip, and of course, it finds nothing.

I do have an idea (*) to solve this problem, but it's cumbersome and might overlap with an existing solution, so I'd prefer to ask the question first.

(*) Create a database, populated with data by `emerge` on each installation/uninstallation, and use a tool that accesses it to replace `qfile`.

[logrusx]

This is a known issue. There were discussions here on the forums but I can't find them. Maybe try looking at the bug tracker, because I think one of the devs mentioned it was being considered.

Another idea is to grep in /var/db/pkg for the symlinks, rather than using information from emerge. It would be easier that way. You don't even need to grep, just populate the DB, all the information is there. Then you can modify it so you can query it in the way you like.

Best Regards,
Georgi

[Frautoincnam]

This is a known issue. There were discussions here on the forums but I can't find them. Maybe try looking at the bug tracker, because I think one of the devs mentioned it was being considered.

I've already searched, and I haven't found anything conclusive, hence my question here.

Another idea is to grep in /var/db/pkg for the symlinks, rather than using information from emerge. It would be easier that way. You don't even need to grep, just populate the DB, all the information is there. Then you can modify it so you can query it in the way you like.

But no, because in /var/db/pkg I'll have the path installed by the package, and that doesn't correspond to the path rkhunter is looking for. That's the heart of the problem. If the path in /var/db/pkg were the path on the filesystem, then qfile would give the correct information, and my question wouldn't make sense.

Code: Select all

# grep "/ip " /var/db/pkg/sys-apps/iproute2-6.17.0/CONTENTS 
obj /bin/ip 6184b13d58bbb226d641f9e789f00d2e 1762840324
# which ip
/usr/bin/ip

[Hu]

The Wiki page linked by the OP includes at the bottom a link to [Tracker] /usr merge. That bug in turn blocks (among others) app-portage/gentoolkit unable to identify which package files belongs to after merge-usr. That is for gentoolkit, not portage-utils as OP reports, but the principle is the same and some of the comments there may be informative.

[grknight]

(*) Create a database, populated with data by `emerge` on each installation/uninstallation, and use a tool that accesses it to replace `qfile`.

This is exactly what is happening with qfile. It asks the emerge installed file database if it installed a certain file. That database says no and qfile reports what it has.

[Frautoincnam]

(*) Create a database, populated with data by `emerge` on each installation/uninstallation, and use a tool that accesses it to replace `qfile`.

This is exactly what is happening with qfile. It asks the emerge installed file database if it installed a certain file. That database says no and qfile reports what it has.

I meant recording the TRUE path, according to symlinks, not the package path registered in package CONTENTS

The Wiki page linked by the OP includes at the bottom a link to [Tracker] /usr merge. That bug in turn blocks (among others) app-portage/gentoolkit unable to identify which package files belongs to after merge-usr. That is for gentoolkit, not portage-utils as OP reports, but the principle is the same and some of the comments there may be informative.

Thanks. Never saw this link. I'll have a look.

[logrusx]

Another idea is to grep in /var/db/pkg for the symlinks, rather than using information from emerge. It would be easier that way. You don't even need to grep, just populate the DB, all the information is there. Then you can modify it so you can query it in the way you like.

But no, because in /var/db/pkg I'll have the path installed by the package, and that doesn't correspond to the path rkhunter is looking for.

Knowing which paths are symlinks, you can modify the database to reflect the real paths.

Best Regards,
Georgi

[Frautoincnam]

Knowing which paths are symlinks, you can modify the database to reflect the real paths.

That's exactly what I'm talking about.

My question wasn't about what I could implement, but about whether something already exists so I don't invent it unnecessarily.

[sublogic]

[ . . .] To see which package this binary belongs to, I run qfile /usr/bin/ip, and of course, it finds nothing.

As a workaround, try running qfile ip without the full path.

If running in a script, do qfile $(basename $filepath) .

One drawback is that you can get multiple hits.

Code: Select all

$ qfile python
dev-lang/python: /usr/lib/python-exec/python3.14/python
dev-lang/python: /usr/lib/python-exec/python3.13/python
dev-lang/python-exec: /usr/bin/python
sys-apps/file: /usr/share/misc/magic/python

(This system is still split-user.)

[Frautoincnam]

As a workaround, try running qfile ip without the full path.

That's a pretty good idea. I wasn't aware of it.

But the fact that it can produce multiple results isn't ideal for me since I've already set up my database.

Code: Select all

# qfile ip
app-shells/bash-completion: /usr/share/bash-completion/completions/ip
sys-apps/iproute2: /bin/ip

But thanks anyway for suggesting it.

[Zucca]

Hm.
Interesting problem.

Code: Select all

zucca@M2-Air ~ $ qfile /bin/ip
sys-apps/iproute2: /bin/ip
zucca@M2-Air ~ $ realpath /bin/ip
/usr/bin/ip
zucca@M2-Air ~ $ qfile /usr/bin/ip
zucca@M2-Air ~ $ 

Resolving symlinks early may give false negative.

Code: Select all

zucca@M2-Air ~ $ qlist sys-apps/iproute2 | grep '/ip$'
/bin/ip

... and since the ebuild file (subsequently probably the makefile) installs the binary into /bin, were it a symlink or not, it's hard to perform an "unresolving of symlinks".

Now that the actual file resides at /usr/bin/ip if user queries that file with qfile, we'd need to know if any component of the path were a target of a symlink somewhere and then expand the query to those locations too. Potentially a very expensive search.

[logrusx]

Potentially a very expensive search.

No, it's not. It's linear time and potential symliks are only a fixed number.

Brute force solution would be M*N where M is the depth of the path and N - the number of fixed symlinks.

Best Regards,
Georgi

[Zucca]

Well yes, if you have some already known fixed locations of common symlinks then it's not too much of a hassle.

[Zucca]

Hm.
Interesting problem.

Code: Select all

zucca@M2-Air ~ $ qfile /bin/ip
sys-apps/iproute2: /bin/ip
zucca@M2-Air ~ $ realpath /bin/ip
/usr/bin/ip
zucca@M2-Air ~ $ qfile /usr/bin/ip
zucca@M2-Air ~ $ 

I found a "solution":

Code: Select all

emerge -qp /usr/bin/ip | cut -d ']' -f 2

Code: Select all

emerge -qp /usr/bin/ip | awk -F '] ' '{print $2}'

I find this rather interesting that it even works... qfile and equery b, both, fail this.

[logrusx]

I find this rather interesting that it even works... qfile and equery b, both, fail this.

Because qfile and equery simply grep in /ver/db/pkg. The emerge command actually spins up portage and is able to do much more stuff. That's even evident from the delay and the fan noise it produces.

You've just found another way to do it. I guess whoever wrote equery or qfile wouldn't have done it if they knew this trick :)

If it at all existed back then as I recall portage had been pure bash up until one point. I'm not sure I've experienced that personally but certainly portage was much less capable 18 years ago when I first tried Gentoo.

Best Regards,
Georgi

[Zucca]

Ok.

I had the impression that equery uses actual portage routines/libs rather than directly querying database.
Haven't really dug into the source code of either q applets or equery.

It makes sens then.

[logrusx]

Now that you mention it, I don't have recollection of where I know that. I think I've seen a developer quote about it but I may be wrong. All I know is equery does stuff the simplest way possible and in regards to that, they both use the same mechanism with qfile.

EDIT: actually I found the thread. It's not exactly what I said but still:

equery belongs, and other tools like qfile, use the portage database and not actual locations.

Best Regards,
Georgi

[Zucca]

portageq kinda works:

Code: Select all

$ portageq owners / /usr/bin/ip
sys-apps/iproute2-6.17.0
	/bin/ip
None of the installed packages claim these files:
	/usr/bin/ip