RPM packaging and ldconfig handling
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.
2. Enable the dynamic linker to load libraries by their soname.
3. Enable the dynamic linker to load libraries in directories listed in
/etc/ld.so.conf and /etc/ld.so.conf.d.
The first point is a performance issue and does not matter in this
context. Item 2 and 3, however, can cause program invocation to fail if
ldconfig is not run and certain changes are made to the system.
The Packaging Guidelines currently require that packages must call
ldconfig if they install or install shared objects:
https://fedoraproject.org/wiki/Packaging:Guidelines#Shared_Libraries
I assume that the goal of the proposal is to reduce both maintainer
overhead and speed up package installation, by removing the ldconfig
invocations from individual packages. This is indeed worthwhile.
However, we need to make sure that when subsequent RPM scriptlets are
executed after the installation or update of a shared object, they see a
system which is usable, so that they can run all the programs listed in
the RPM dependencies.
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
But this will run at the end of the transaction, which is too late for
other scriptlets (which, for %post, run immediately after unpacking an
RPM package).
It would not be a good idea to turn the triggers into %filetriggerin and
%filetriggerun, in my opinion. They would run after the installation of
the package, but since the paths specify entire directory trees, the
trigger would fire for the installation of many noarch packages to due
to the /usr/lib path (e.g., Python packages are installed into
/usr/lib/python*/site-packages/bugzilla).
We can still skip running ldconfig if we can otherwise make sure that
the symbolic links for the DSO sonames are available, so that we simply
have a minor performance issue. ldconfig would still have to be run by
%transfiletriggerin and %transfiletriggerpostun to optimize the system,
but the precise point at time when this has to happen does not matter,
except that it should happen after RPM removed all files to be deleted
during the RPM transaction (which generally happens toward the end,
during the cleanup phase, and not immediately after the installation of
a different package version). As far as I can tell, even with a
successful cache lookup, the dynamic loader still uses the soname
symbolic link to open the DSO file, so renaming the implementation name
(say, for libc-2.25.so to libc-2.26.so) would not lead to temporary
breakage.
We would however make sure that at RPM packaging time, the symbolic
links are created automatically (otherwise the goal of reducing
maintainer overhead would not be met).
For item 3 (shared objects in non-default directories), I think the
proposed change for the glibc:
%filetriggerin -p /sbin/ldconfig -P 2000000 -- /etc/ld.so.conf.d
%filetriggerun -p /sbin/ldconfig -P 2000000 -- /etc/ld.so.conf.d
should work in most cases, except when the configuration file is in a
separate -common package which might not be (un)installed before or
after the package which contains the DSO file (so that the automatic
ldconfig invocation does not happen at the right point in time).
However, these packages are rare, so perhaps it would be preferable to
keep the explicit ldconfig invocations in the packages for explicitness
(and generally discourage the use of non-default search paths).
For all these triggers, we need to carefully consider the -P priority
value and document it in the Packaging Guidelines.
In any case, I don't think we can just make a change to the glibc
package, an update of the Packaging Guidelines is needed as well, if
only for the “must call ldconfig” part.
Thanks,
Florian