Hello, As you may or may not know, right now env-update calls 'ldconfig' by default, describing that in the terms of 'Regenerating /etc/ld.so.cache'. In fact, it does a little more -- it updates library symlinks to use the newest library version available.
In other words, if we've got libfoo.so.1.1 and .1.2 with the same SONAME, and libfoo.so.1 symlinks to .1.1, ldconfig would replace that by a symlink to .1.2. This seems to be the major cause of the problems with portage's preserve-libs feature. When a package is downgraded, portage replaces the SONAME symlink with an older version to make newly-built packages use that older version, and preserves the newer libraries not to break linkage. But a short while later, ldconfig takes over the symlink and makes it point to the newer version once again. Packages still link to the newer version and the only way to get the library actually downgraded is to remove the preserved library. Thus, it's even worse than without preserved-libs. On the other hand, that ldconfig behavior seems completely redundant as packages are installed with .so symlinks anyway. And I think that if package manager installs those symlinks, it should manage them itself instead of letting external tools mangle with PM-installed files. I have created a patch which makes 'env-update' always pass '-X' to ldconfig, to not let it update the symlinks in system-wide libdirs. I'm testing it right now to see if it doesn't cause any breakage. If that causes problems (i.e. some packages don't actually create correct .so symlinks themselves), I guess we could decide to call 'ldconfig -N -n' in post-install operations, like the deprecated 'preplib' helper does. This way, the symlinks will be completely controlled by the Package Manager and the preserve-libs feature should handle downgrades just fine. And I've just downgraded libav, and rebuilt mplayer2 against it with the newer version being preserved just fine. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
