(After reading through many complaints about ldconfig overhead on fedora-devel@ 
...)

RPM has all the necessary information in header metadata to precisely perform 
what ldconfig does only when necessary without any assistance from 
/bin/ldconfig or packagers.

While the recent proposals to macroize (and hence standardize) /bin/ldconfig 
invocations in scriptlets are perfectly sane, the problem(s) of install 
overhead, due to exec(2) closing open fdno's, and excessiv invocations, cannot 
be solved with Newer! Better! Bestest! macros and packaging policy enforcement.

If anything, the change to add fsync/fdatasync to /bin/ldconfig cache handling 
are surely going to increase the overhead 
https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=elf/cache.c;h=e63979da7d25560c4072cca99749e879005c5c2f;hp=c2c010f97bb23d2b568e6499e5806dac73211da3;hb=999a6dab3ee1c8e77bb348ba2389e7aeb5c062b2;hpb=52a01100ad011293197637e42b5be1a479a2f4ae

Internalizing /bin/ldconfig in rpm is quite feasible: it's not difficult to add 
symlinks and maintain a cache file in sync with changes performed by RPM 
thereby fully automating the operations as a side effect of installing a DSO 
from an rpm package.

In fact, that is exactly what the FreeBSD pkg command does: 
https://github.com/freebsd/pkg


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/405
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to