problem using equery belongs after running merge-usr

[kilua]

I am having a simple problem after I run the merge-usr script in my desktop. The problem is that equery belongs is not finding the files in the new location. For example,

Code: Select all

type bash
bash is /usr/bin/bash

Then,

Code: Select all

equery b /usr/bin/bash
 * Searching for /usr/bin/bash ... 

and nothing is found. If, instead, I ask using the "old location"

Code: Select all

equery belongs /bin/bash
 * Searching for /bin/bash ... 
app-shells/bash-5.1_p16-r4 (/bin/bash)

I receive the expected result. Is there any way to make equery belongs work with the /usr locations?

Thanks!

[grknight]

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

The merge-usr script bypasses updating the database and just moves files.

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.
The only benefit is the database output.

[kilua]

Thanks grknight for your quick feedback. As a simple test, I have re-emerged the bash package. Still, I see no change, I mean, neither qfile nor emerge belongs are able to find /usr/bin/bash. Am I missing or misunderstanding something?

[dreadnought]

*bump*

I see the exact same behavior after
- switching to default/linux/amd64/23.0/split-usr
- completing all steps from news item, finalizing with emerge --ask --emptytree @world
- running merge-usr
- switching to default/linux/amd64/23.0

[logrusx]

*bump*

I see the exact same behavior after
- switching to default/linux/amd64/23.0/split-usr
- completing all steps from news item, finalizing with emerge --ask --emptytree @world
- running merge-usr
- switching to default/linux/amd64/23.0

3. If you are currently using systemd in a split-usr configuration, then first
complete the migration to the corresponding merged-usr profile of the
same profile version.

I cannot say that's the problem, but you've messed the order. I'm not aware of a merge procedure for 23.

Best Regards,
Georgi

[grknight]

I cannot say that's the problem, but you've messed the order. I'm not aware of a merge procedure for 23.

However, this is an OpenRC profile (default/linux/amd64/23.0/split-usr) which #3 says:

Code: Select all

If you are currently using openrc, migrate to 23.0 first, keeping your disk
   layout. If you want to move from split-usr to merged-usr, do that afterwards.

[logrusx]

I concluded it was systemd because unless I'm wrong, nothing necessitates merged-usr for openrc profiles.

Best Regards,
Georgi

[dreadnought]

regardless of the init system...

is there a way to fix equery belongs? re-emerging packages after merge-usr does not seem to fix the portage db path entries:

Code: Select all

# emerge -1 bash
# which bash
/usr/bin/bash
# equery b /usr/bin/bash
 * Searching for /usr/bin/bash ...
# equery f bash
 * Searching for bash ...
 * Contents of app-shells/bash-5.1_p16-r6:
/bin
/bin/bash

[logrusx]

Better file a bug and discuss it with the developers. It might be something recent as I don't remember having such issues after migration.

Best Regards,
Georgi

[e8root]

Thanks grknight for your quick feedback. As a simple test, I have re-emerged the bash package. Still, I see no change, I mean, neither qfile nor emerge belongs are able to find /usr/bin/bash. Am I missing or misunderstanding something?

On my systemd profile converted from split-usr back in the good old days of 17.1 profile and then updated to 23.0 and reemerged with --emptytree world it doesn't show anything for /usr/bin/bash but it does show app-shells/bash-... for /bin/bash.

I made quick python script to equery belongs all items in /bin for both /bin and /usr/bin and it seems most packages show the same results for both locations and are correctly point to /usr/bin location. What I guess happens is that equery belongs have mechanism implemented to follow symlinks but if the file is installed in now symlinked directory like /bin it cannot figure out which package this file belongs if we search it in original directory in /usr/bin

Perhaps possible area of improvement in equery belongs?

[freke]

Bug for this does exist - https://bugs.gentoo.org/927640

[logrusx]

regardless of the init system...

is there a way to fix equery belongs? re-emerging packages after merge-usr does not seem to fix the portage db path entries:

Code: Select all

# emerge -1 bash
# which bash
/usr/bin/bash
# equery b /usr/bin/bash
 * Searching for /usr/bin/bash ...
# equery f bash
 * Searching for bash ...
 * Contents of app-shells/bash-5.1_p16-r6:
/bin
/bin/bash

Actually it turns out this scenario does not work for me either. I believe this hasn't changed recently and I just haven't run into the situation previously.

Maybe the ebuild installed in /bin and I vaguely remember something about equery and symlinks. I don't remember details, but thinking about it, there's no way to say which link points to the file you're checking and equery cannot do anything other than checking what's in the database. If it says /bin/bash, then there's no way of knowing /usr/bin/bash has a symlink /bin/bash pointing to it.

Best Regards,
Georgi

[Genone]

regardless of the init system...

is there a way to fix equery belongs? re-emerging packages after merge-usr does not seem to fix the portage db path entries

Neither equery nor the portage db entries are broken, the bash ebuild explicitly only installs /bin/bash, not /usr/bin/bash:

Code: Select all

	dodir /bin
	mv "${ED}"/usr/bin/bash "${ED}"/bin/ || die
	dosym bash /bin/rbash

So the equery files output is correct.

The issue here is that you now have /bin as a symlink to /usr/bin, so the merge process obviously does put the bash binary into /usr/bin, but it might not even be aware about this (if you copy files into a symlinked directory manually you don't get feedback either that it ended up in a different physical location). Even if it would know about this, it is questionable if it should do anything about this (like replacing /bin/bash with /usr/bin/bash in the db). equery and related tools also have a hard time dealing with this as symlinks only work in one direction: You can resolve /bin/bash -> /usr/bin/bash, but if you only know about /usr/bin/bash it is tricky+expensive to find the /bin/bash symlink pointing to it.

Easiest workaround would probably to add some nasty special case hacks for the merged-usr symlinks, so any query for files in /usr/bin, /usr/lib, /usr/sbin and /usr/lib64 will also look in their non-usr counterparts. Doesn't solve the general problem, but then I'm not sure wether that can be solved properly.

[e8root]

One way to do it is if the search returns nothing just check if there are any files with the same name and then check if they maybe reside in symlinked directory to one which we pointed to. In this case we don't find bash in /usr/bin/ but we can see that there is bash in /bin/... and it points to /usr/bin/ so we have a hit. It wouldn't even need additional pass through list of files and in most cases there wouldn't be duplicate file names so it should not incur additional symlink checking in case we do not find perfect match.

[Banana]

I kind of hijacked the https://bugs.gentoo.org/927640 since https://packages.gentoo.org/packages/app-portage/pfl is affected with the same problem. pfl and the e-file command does find /usr/bin/bash and /bin/bash now.