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
