On Sun, Jan 14, 2018 at 6:13 PM, Tomasz Kłoczko
<kloczko.tom...@gmail.com> wrote:
> On 14 January 2018 at 16:38, Igor Gnatenko
> <ignatenkobr...@fedoraproject.org> 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**.
>
I'm not sure you're aware of this, but the GNU C Library serves more
than Linux. While Linux VFS is much better than it was 20 years ago,
other OSes are not necessarily so.
> 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.
This is easy to fix. I could just do it using /%{_lib} and %{_libdir} instead.
> 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.
It's pretty trivial to do that behavior. For example, we could just
have a posttrans trigger that runs a program that decides all the
things based on what the filesystem looks like (Solus does this with
usysconf[1]). But that means the tool needs to know how to decide what
to run.
[1]: https://github.com/solus-project/usysconf
> 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.
>
If we wanted less scriptlets in packages and singular set of triggers
across the board, it would technically be possible. But the penalty
for that is that the package manager must figure out how to evaluate
what to run. You don't get to get away from that logic.
> 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)
>
This is not a particularly helpful comment. Solaris' crle is not
demonstratively better than current ldconfig configuration via drop in
directories. Personally, I prefer the latter because you can preload
search paths pretty trivially without requiring an execution
environment.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
