Re: Delayed ldconfig execution in postinst step
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. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: