Re: Another solution (was Re: All services that require a restart from libc6 upgrade...)
On Thu, 19 Oct 2000, Anthony Towns wrote:
> On Tue, Oct 17, 2000 at 11:36:59PM -0400, Ben Collins wrote:
> > It loads libnss_*.so.2 (* being "files" or "nis" or whatever). See the
> > problem now? It can't use the *-2.1.3.so, because not all NSS modules are
> > compiled with glibc, and even if they used that same convention, it would
> > be next to impossible for them to stay in sync.
>
> Except that if libnss_strange.so.2 isn't as tightly synchronised with glibc
> as others (ie, you can mix and match the libnss and glibc versions), then
> there's not an issue. If it is tightly synchronised, then it needs to be
> properly versioned.
This makes sense to me.
If properly done, then naively, it would seem that the solution is for
glibc's name resolver to attempt to open libnss_*-2.1.3.so, and if that
fails, then to fall back to libnss_*-2.so. During the upgrade to 2.1.4,
the new libnss_* files get installed, but the old ones are left. A
running daemon with the old libc mapped should get the right libnss_*.so,
is it not so?
-S
Reply to: