On Sun, Jan 14, 2018 at 6:13 PM, Tomasz Kłoczko
<kloczko.tomasz(a)gmail.com> wrote:
On 14 January 2018 at 16:38, Igor Gnatenko
<ignatenkobrain(a)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!