Re: ldconfig warnings
Adam P. Harris wrote:
> >Seems as if the ldso maintainer and the dpkg maintainer were the two best
> >candidates to providing that explanation.
Cc'd to them.
> Maybe that's not necessary. Rob Browning post got me thinking: even if
> you create the symlink in `debian/tmp/...', order it properly w.r.t. the
> actual shared lib, you do still need to call ldconfig in postinst in
> order to update /etc/ld.so.cache.
I belive that is correct. David Engel can tell us for sure.
> Is this the issue? It would be a pretty simple addition to Ch 12 of the
> Packaging Manual.
I don't think it's that simple. Let me quote the manual again:
| If you do the above your package does not need to call ldconfig in its
| maintainer scripts. It is especially important not to call ldconfig in
| the postrm or preinst scripts in the case where the package is being
| upgraded (...) as ldconfig will see the temporary names that dpkg uses
| for the files while it is installing them and will make the shared
| library links point to them, just before dpkg continues the
| installation and removes the links!
Pay especial attention to the end of that quote. This is a real problem. When
I was packaging aalib, I had it call ldconfig. Then, I read this. I slowed
my system down to a crawl with some spin loop code, and then installed
aalib. While aalib was installing, I ran "ls /usr/lib/aalib*" repeatedly in
another xterm. What I saw happen was just as the policy manual described: as
the package installed, dpkg made aalib.so.*.dpkg-tmp files, then ldconfig
was run, and symlinks where made pointing to them.
This doesn't seem to happen always. Is it a race condition? (I don't see
how). Maybe it has to do with if you're upgrading. Anyway, I saw it happen.
It's a real problem and we have to figure out a way to deal with it if
indeed we need to run ldconfig to make it update ld.so.cache. (One way would
be to hack ldconfig to ignore the dpkg .tmp files.)
--
see shy jo
Reply to: