On 14 January 2018 at 16:38, Igor Gnatenko <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote: > On Fri, 2018-01-12 at 15:00 +0100, Florian Weimer wrote: >> The glibc team has received a request to change the way ldconfig >> invocations during package installations and deinstallations are handled. >> >> https://src.fedoraproject.org/rpms/glibc/pull-request/5 >> https://bugzilla.redhat.com/show_bug.cgi?id=1380878 >> >> Some background: ldconfig serves several functions. Key aspects are: >> >> 1. Speed up programing loading. I think that at least someone in glibc team should start to consider drop completely use ld.so.cache. This "speedup" mechanism was invented more than two decades ago when it was the problem with VFS layer caching. The same "loading time issues" have been driving in latex use kpathsea. Both techniques today are more or less **obsolete**. Other Unixes like BSD* and Solaris instead focusing on ld.so latency started improving VFS caching and results now are equal from point of view of execution latency None of the BSD* or Solaris ld.so are using not using any ld.so. cache and are using only more sophisticated configuration framework which allows, for example, mask not use exact file which provides SONAME to use another one which provides such SONAME from the non-standard paths. As result ld.so is not forced to load few hundreds KB cache file, it stat()s and open()s blindly <libdir>/<SONAME> file relaying 100% of VFS. In other words instead of fighting with the fact that below {,/usr}/lib{,64} or another subset of cases would be possible to drop use ldconfig, simplify ld.so and at the end remove all %post/%postun /sbin/ldconfig execution. Instead, all of this could be introduced crle command like on Solaris. crle man page https://docs.oracle.com/cd/E19109-01/tsolaris8/835-8001/6rutvdvik/index.html Performance of the not use cache is easy to test by simple remove /etc/ld.so.cache and observe ld.so by executing "LD_DEBUG=statistics </something/to/execute>". Example: $ LD_DEBUG=statistics ls -d /etc 23174: 23174: runtime linker statistics: 23174: total startup time in dynamic loader: 6135538 cycles 23174: time needed for relocation: 2876398 cycles (46.8%) 23174: number of relocations: 629 23174: number of relocations from cache: 3 23174: number of relative relocations: 1582 23174: time needed to load objects: 2304750 cycles (37.5%) /etc If those statistics will be not enough probably other people will propose other/better method showing that using ld.so.cache still is necessary or could be dropped. Solaris crle man page https://docs.oracle.com/cd/E19109-01/tsolaris8/835-8001/6rutvdvik/index.html [..] >> The latest proposal has this change for the glibc spec file, in order to >> deal with the issue of item 2: >> >> # File triggers for when libraries are added or removed in standard paths >> %transfiletriggerin -p /sbin/ldconfig -P 2000000 -- /lib /usr/lib /lib64 >> /usr/lib64 >> >> %transfiletriggerpostun -p /sbin/ldconfig -P 2000000 -- /lib /usr/lib >> /lib64 /usr/lib64 BTW it is yet another small issue with those file triggers. Build process described in glibc.spec build 32 or 64 bits versions of the binaries. ldconfig is part of the main glbc package and it is possible on x86 install glibc.i386 and glibc.x86_64 When both ABI versions packages are installed those file triggers will be executed two times. All this is result another rpm weakness that all global actions (aka in rpm semantics triggers) must be defined not package manager set of the trigger but only in packages. Just for the compare .. IPS has the strict and finite set of analogues of the triggers called actions. ***NONE*** of the packages definitions contains any actions definitions and all works perfectly causing that whoever is responsible for building packages has no opportunity to mess in this area BY DEFINITION. BTW .. IPS has no at all possibility to add any post/postun/trans scripts. IMO it is only matter of time when rpm developers will spot that all this stuff in spec files is only constant source of problems. People moving away from SySV packages which implemented IPS come to this brilliant observation DECADE ago. It may take on Linux next decade to "reinvent the wheel" but I'm 100% that all those scripts embedded in packages sooner or later will be removed. Conclusion: so far I've been actively supporting add glibc file triggers by trying to add my comments discussion in bugzilla tickets. However, as I have in my head quite deep knowledge of other operating systems recently I found see now WAY better solution which does not increases current entropy and/or is Ockham Razor compliant solution (https://en.wikipedia.org/wiki/Occam%27s_razor) So again this solution should consist of: - remove use ld.so,cache by ld.so - remove ldconfig and all /sbin/ldconfig in all spec files - add crle or crle like command (knowing Linux NIH probably it will end up on crle like command) BTW: above could be introduced very quickly without touching glibc code by simple /etc/ld.so.cahe and use ldconfig. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
