Re: Delayed ldconfig execution in postinst step
#include <hallo.h>
* Bill Allombert [Tue, Mar 14 2006, 04:20:28AM]:
> 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.
Counter-proposal: write a more generic program (see my specification on
the mentioned Wiki page) and use that one as replacement or wrapper for
"ldconfig" or "update-menus", etc. - so the new update-menus would just
run "dpkg-hook update-menus.real".
And you can reuse your dpkg-lock-change detecting code in this program,
however I have explicitely planed a wrapper for dpkg itself because IMO
the detection of dpkg exit should be synchronized with the hook
execution. Your current solution simply forks the thing away and you
newer know what it does or when it's done.
> 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.
Yes, therefore the --add-option ... mechanism proposed by Goswin.
Btw, I just noticed that your /usr/bin/update-menus program does
exactly... nothing! I cannot remember the rationaly behind that but
since they are part of the same package (and either both exist or
none).
Eduard.
--
<CHS> argl bin i deppert
Reply to: