[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

Bill. <ballombe@debian.org>

Imagine a large red swirl here.

Reply to: