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
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
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
And I've just downgraded libav, and rebuilt mplayer2 against it with
the newer version being preserved just fine.