On Sun, Mar 12, 2006 at 01:56:13PM +0100, Eduard Bloch wrote: > Hi people, > > I just wondered why exactly my laptop uses that much time for updates > and I think that calling ldconfig is a main problem. In theory, it > should not cost much time because VFS cache has the relevant file parts. > However, if memory is limited and there are other applications running, > the VFS cache is flushed sooner thank you think, especially with > today's count of various libraries in /usr/lib. > > I think, it would be enough to call ldconfig only once after dpkg is > trough. Reasons: > > - there are no dangerous transitions (libc5->libc6) that would require > having updated ld.so.cache immediately > - all applications should follow the ld.so.conf paths if something is > not in the cache. No problem here. > > The simplest idea for implementation is just having a script called > ldconfig, put in the PATH of dpkg. It registers ldconfig calls, waits > for the termination dpkg and runs /sbin/ldconfig. > > Any objections, ideas? There may be corner cases where that assumptions > do not work but if we integrate this into the distribution, we can find > and fix the problems really soon.
Hello debian-developers, I offer to implement a update-ldconfig program that would work the same way update-menus work, by checking a lock and forking in the background and waiting for the dpkg lock. Another fix would be to have an incremental ldconfig which only update the libraries passed on the command-line. That would have the nice side effect of not uselessly changing the atime of all the libraries, thus barring popcon to report it. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
