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