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

Delayed ldconfig execution in postinst step

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.

<GyrosGeier> doogie, 25 m/s is pretty fast
<doogie> 40m/s from apache
<doogie> 25m/s is from java
<GyrosGeier> doogie, that's about 8 km/h.

Attachment: signature.asc
Description: Digital signature

Reply to: