Project Talk:Toolchain/Corrupt VDB ELF files
I believe this to be a very specific corner case under unusual circumstances. I tested this script on at least 3 installs and all had hits that were mostly false-positives. What I mean by that is they were internally (same package) shared files outside the SOPATH like in /usr/libexec. While it was good to rebuild, it had no real changes to the rest of the system. I don't mind if I am proven incorrect but I don't believe this to be a major concern. --Grknight (talk) 12:39, 28 September 2021 (UTC)
A few points:
- It'd be really useful to have the output from runs which were false positives. It's hard to act on something I can't directly test;
- It requires more effort to determine if anything uses those libraries because other packages might be installed with a certain RPATH - my primary concern here has been making sure Portage can act consistently (and the VDB has the entries it would in normal circumstances);
- I don't think you're wrong that certain people might be fine, but it is certainly a major concern if someone is affected. And the nature of it is such that someone might be affected quite some time after the corruption occurred (when some package required finally changes SONAME, possibly months or years later).
- For quite some time, this was a regular occurrence with glibc upgrades, and the dependency resolution order is not something we can predict for every user. That is, it's not really easy to say "just these packages are affected" with a hardcoded small list.
- (The reason I suggest rebuilding everything is because I don't particularly want people to rely on the tool munging the VDB permanently.)
- Given this, I've tended towards being conservative. I've added some bold to the '-e @world' advice though.