Ok, I've now caught up with the bugzilla discussion, including that you have 
decided to deploy an incomplete solution and not handle ld.so.conf.d changes 
(though all the bizarre variants and performance were noted and discussed).

IMHO it's still easier to just handle symlink creation and cache update as a 
direct side effect of installing a DSO file.

No lua, no database retrievals, no fork/exec (and close(fdno) overhead), no 
obscure abstractions, no false runs when some directory is changed by a non-DSO 

The place to do so is immediately after temp files are renamed into place in 
what (used to be) lib/fsm.c. 

I would also not bother packaging symlinks into headers, but rather leave the 
creation/removal as part of DSO handling.

Note that embedding ldconfig into rpm would also permit a --verify 

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Rpm-maint mailing list

Reply via email to