On 11 September 2012 13:27, Andreas Jaeger firstname.lastname@example.org wrote:
On Tuesday, September 11, 2012 13:55:04 Michal Vyskocil wrote:
On Tue, Sep 11, 2012 at 09:31:21AM +0200, Andreas Jaeger wrote:
On Monday, September 10, 2012 18:38:57 Cristian Rodríguez wrote:
El 10/09/12 18:08, Dimstar / Dominique Leuenberger escribió:
You need to move the ldconfig call to the libhttrack2 sub package:
%post -n libhttrack2 -p /sbin/ldconfig %postun -n libhttrack2 -p /sbin/ldconfig
%post without -n <name> implies having the post on the main package; which in your case does not need it, as the lib lives in a sub - package.
That being said, I wonder why we still need this in the first place, will it be possible to teach the linker to "keep an eye" on libraries already in the cache with inotify and rebuild it automagically when needed ?
You don't need it - the dynamic linker ld.so, e.g. on x86-64 it is /lib64/ld-linux-x86-64.so.2, will first check the cache and then check the filesystem.
Invoking ldconfig from ld.so would be really bad - and implementing ldconfig as a daemon is also not worth it.
you don't need to do so - all you need is to have proper systemd generator reads the /etc/ld.conf and /etc/ld.conf.d/* to make the proper .path service
which will trigger the ldconfig
Then, you can freely drop the ldconfig from %post scripts out.
Let's switch to systemd by default ;)
Is there a way to limit this so that it doesn't get run too often?
If that would be possible it would be the most similar thing to (not existing) rpm file triggers. It could be used for new MIME types, extraction of applications supported mime types from .desktop files and regeneration of GTK icon cache.