On Fri, Jan 12, 2018 at 9:00 AM, Florian Weimer <fweimer@xxxxxxxxxx> 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. > > 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). > The fact that noarch Python site-packages exist in /usr/lib has always bugged me. I don't know why it's that way or if there's something that can be done about it in Fedora and upstream to move them to /usr/share. But I don't think it's the only ecosystem like that, which is why they are %transfiletriggers. That said, in the nearly 10 years that the Mandriva family has been using file triggers for running ldconfig, it hasn't caused any major issues. Heck, the file triggers that have been proposed are more comprehensive than the existing ones used in Mageia, to cover things like the usage of RemovePathPostfixes in some RPM packages as well as dealing with packages with non-standard paths. Honestly, the worst case scenario is that "weird" packages going into paths like /opt/foo/baz/lib64 would need to still run ldconfig, but that's only if they don't drop a file into /etc/ld.so.conf.d and don't use rpaths. > 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). > There's been a PR upstream in rpm[0] for a while now to support a more comprehensive buildroot policy (brp) based on the Mandriva/Mageia spec-helper[1] stuff. One of the components of that PR is running ldconfig in the buildroot to produce those DSO links[2]. We could pull that in and adjust redhat-rpm-config to disable the ones we don't want. There's also an issue for making brp stuff better[3]. [0]: https://github.com/rpm-software-management/rpm/pull/122 [1]: http://gitweb.mageia.org/software/rpm/spec-helper/ [2]: https://github.com/rpm-software-management/rpm/pull/122/files#diff-c1bf327bbc4f83e504b1defa067006e0 [3]: https://github.com/rpm-software-management/rpm/issues/308 > 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 what sense do you want the priority value documented as? Do you want it to be "no file trigger in Fedora can use a priority value higher than this", or something else? > 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. > I think this is a really easy change to make. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
