Re: Preparing for glibc 2.34: library locations

[Florian Weimer <fweimer@redhat.com>]

* 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