On Wed, Sep 01, 2021 at 11:01:01AM +0200, Florian Weimer wrote: > * Dan Čermák: > > > it has been recently proposed to switch openSUSE to run ldconfig via a > > %transfiletriggerin/-un scriptlet instead of manually in %post & %postun > > the same way as Fedora does it at the moment. > > > > However, an interesting issue has been raised: what happens if package A > > gets upgraded in the same transaction as package B, but B needs A during > > the upgrade. A will install a new shared library, but ldconfig will run > > after B has already tried to upgrade. > > Fedora ships the soname links in the package, addressing this issue. > For example, openssl-libs contains: > > /usr/lib64/libcrypto.so.1.1 > /usr/lib64/libcrypto.so.1.1.1k > /usr/lib64/libssl.so.1.1 > /usr/lib64/libssl.so.1.1.1k > > As a result, running ldconfig is purely an optimization. > > There are some packages that install fails into /etc/ld.so.conf.d, and > such packages still have to run ldconfig explicitly. (We should perhaps > move those shared objects to /usr/lib64, too.) It has always struck me that ldconfig's impl isn't a great match for RPMs use case. IIUC ldconfig scans all files in all registered library directory paths, since it doesn't know what files might have changed since its last run (or does it check mtime at all to optimize work it does?) RPM meanwhile definitely knows exactly what files it has just created/deleted/modified and thus need ldconfig processing. Is there scope for optimizing ldconfig, or provide an alternative impl, that is able to process /only/ the libraries that RPM has just touched and thus not scan any other files or directories ? ie make it a non-issue if ldconfig is invoked many times, by ensuring each invokation would only do a tiny bit of work. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
