| View previous topic :: View next topic |
| Author |
Message |
kilua
n00b
Joined: 22 May 2006
Posts: 19
|
 Posted: Thu May 25, 2023 5:18 pm Post subject: problem using equery belongs after running merge-usr |
 |
|
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: | type bash
bash is /usr/bin/bash
|
Then,
| Code: | equery b /usr/bin/bash
* Searching for /usr/bin/bash ...
|
and nothing is found. If, instead, I ask using the "old location"
| Code: | 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! |
|
| Back to top |
|
 |
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1661
|
| Posted: Thu May 25, 2023 5:35 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
kilua
n00b
Joined: 22 May 2006
Posts: 19
|
| Posted: Thu May 25, 2023 6:18 pm Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
dreadnought
n00b
Joined: 09 Jun 2004
Posts: 21
Location: Linz, Austria
|
| Posted: Mon Mar 25, 2024 7:31 pm Post subject: |
|
|
*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 |
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1539
|
| Posted: Mon Mar 25, 2024 8:17 pm Post subject: |
|
|
| dreadnought wrote: | *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 |
| Profile upgrade to version 23.0 available wrote: | 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 |
|
| Back to top |
|
|
grknight
Retired Dev
Joined: 20 Feb 2015
Posts: 1661
|
| Posted: Mon Mar 25, 2024 8:20 pm Post subject: |
|
|
| logrusx wrote: | | 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: | 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. |
|
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1539
|
| Posted: Mon Mar 25, 2024 8:26 pm Post subject: |
|
|
I concluded it was systemd because unless I'm wrong, nothing necessitates merged-usr for openrc profiles.
Best Regards,
Georgi |
|
| Back to top |
|
|
dreadnought
n00b
Joined: 09 Jun 2004
Posts: 21
Location: Linz, Austria
|
| Posted: Tue Mar 26, 2024 10:38 pm Post subject: |
|
|
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: |
# 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
|
|
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1539
|
| Posted: Wed Mar 27, 2024 7:47 am Post subject: |
|
|
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 |
|
| Back to top |
|
|
e8root
n00b
Joined: 09 Feb 2024
Posts: 71
|
| Posted: Wed Mar 27, 2024 8:52 am Post subject: |
|
|
| kilua wrote: | | 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?
_________________
Unix Wars - Episode V: AT&T Strikes Back |
|
| Back to top |
|
|
freke
l33t
Joined: 23 Jan 2003
Posts: 977
Location: Somewhere in Denmark
|
|
| Back to top |
|
|
logrusx
Veteran
Joined: 22 Feb 2018
Posts: 1539
|
| Posted: Wed Mar 27, 2024 10:40 am Post subject: |
|
|
| dreadnought wrote: | 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: |
# 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 |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9532
Location: beyond the rim
|
| Posted: Wed Mar 27, 2024 12:01 pm Post subject: |
|
|
| dreadnought wrote: | 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: | 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. |
|
| Back to top |
|
|
e8root
n00b
Joined: 09 Feb 2024
Posts: 71
|
| Posted: Wed Mar 27, 2024 9:18 pm Post subject: |
|
|
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 [i]/usr/bin/[i] 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.
_________________
Unix Wars - Episode V: AT&T Strikes Back |
|
| Back to top |
|
|
Banana
Veteran
Joined: 21 May 2004
Posts: 1392
Location: Germany
|
|
| Back to top |
|
|
|
Portage & Programming
