* Michael Hudson-Doyle: > (but then, dpkg is not > impacted by the symbolic link issue as far as I know). > > Is this problem written up somewhere? I only subscribed to libc-alpha > a few weeks ago.
I've written about it in various places. As far as I know, it's specific to how RPM performs package updates. Files removed in an update are only removed towards the end, after all work on *all* packages has been done. With the previous approach, this means that when downgrading from glibc 2.29 to glibc 2.28, during the update, there are files ld-2.28.so ld-2.29.so libc-2.28.so libc-2.29.so RPM immediately updates the dynamic linker symbolic link target from ld-2.29.so to ld-2.28.so. But if ldconfig is invoked, it will prefer libc-2.29.so over libc-2.28.so as the provider of the soname libc.so.6, and update the symbolic link and cache to point to libc-2.29.so. That is of course no good once the downgrade is finally completed and libc-2.29.so is removed. The dynamic linker and the libc.so.6 symbolic link can also become desynchronized, and then failures happen earlier during the update procedure. I believe dpkg handles file removals during upgrades/downgrades before running scripts, so it shouldn't suffer from this problem. But I believe the simplification is still worth it. Thanks, Florian