!!! existing preserved libs: >>> package: sys-fs/udev-196-r1 * - /lib64/libudev.so.0 * - /lib64/libudev.so.0.11.5 * used by /opt/google/chrome/chrome (www-client/google-chrome-25.0.1364.29_beta176005) That libudev.so.0 is apparently quite old, but chrome still links to it. How does that work when one installs the newer udev (libudev.so.1) directly, so that the old file cannot be preserved? As chrome really has the file in NEEDED (and does not dlopen it), I assume it is not safe to delete it?
Try latest version, google-chrome-26.0.1386.0_alpha177362
Add www-client/google-chrome to /etc/portage/package.unmask. It could be we need to unmask newer version rather sooner than later. Otherwise google-chrome needs to bundle prebuilt copy of libudev.so.0 propably.
And bit off-topic: stop using udev-196, it has wrong udevdir= in udev.pc and installs all files into wrong directories, and causes other packages to install them into wrong directories. udev-196 was restored to portage only for systemd-196 temporarily, nobody should use it, since systemd-197 was added to Portage today.
Short answer: It is safe to remove /lib64/libudev.so.0* manually. google-chrome uses a dirty hack to get google-chrome to load libudev.so.1 as if it were libudev.so.0: Long answer: Google chrome installs a wrapper script which sets LD_LIBRARY_PATH=/opt/google/chrome. /opt/google/chrome/libudev.so.0 is a symlink to /usr/lib/libudev.so. Recent versions of udev install /usr/lib/libudev.so as a symlink to libudev.so.1. I don't think there is any sane way to fix the preserve-libs issue, as this use case is a bit unorthodox.
Thanks Mike, now I know at least howto handle this next time.
