-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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. > > 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). We can switch it to %filetrigger* at least for beginning in order to stop asking people to write /sbin/ldconfig manually. Effect will be same, but at least it will not put work on packagers heads. > 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). It is possible to filter files in scriptlets to not run it on random files. > 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). As Neal mentioned, it should be possible with very simple brp script. > 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. As Jason pointed, he doesn't see value of having priority documented in guidelines, it is just some value chosen by glibc (or, rather, by person who sent PR).. > 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. Since it doesn't hurt anyone, it can be done without update of guidelines.. But Jason wrote that he will update it guidelines once he will get some free time. - -- - -Igor Gnatenko -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpbh6MACgkQaVcUvRu8 X0xsog//d/lBm90h6BZvq+ZvhZjO8Q96XeZzA8tvmxDAv6+98Z8bP0ZN4KK6Y1zX zKYG7/s7gSke0yBrEkbbh6tMwkQcgBxRbU0JxIEKITFpaeVE3es9JvE79/S8aIFg w2llNTOeP+yjcZ+i6e05ILZRW+RDY8bkZKSlsqHSO88tAQ+D65rgIeZur5OVDBT7 Sq1aqrHobOznD4lYTIK7EMHniLIJlh+lxRwiVkn6f0iM52UmG1uvpOu4VSFN6rBg k3SMbiyxxuBrmfuD+mNOhc08N7fRzz2eOPr/srGXIag7OLrvMd6YVjtH68VWNIOa 9LIZHVSXdI0nGR19ri3qTOEf6ulY/dxfktc6sCCT/5m2zranL8Lk5R1s/PJHeJR5 m2JtoffhWhHHfp+T+LdgxDNSj34vtH1DANEheXO2MJPCvoDVB8kS8qVnEuoVHYhT CxD74xQr0t/nb8sfRFptFV4d+MB6Rnc4bvLNQUTBar61Kk47JmtLl7vsdRevWvKB gtTD8IKrou6nMs9EhYO1K9vs/8zttDsB2hjSAlC3l4m58v3PL6IFmtII9usfXgH3 Cqa2+HlmvC9LLXZSQruFmaHZLK1OI/F7WCGoGZFzwH0C7s4eUwurAvBhF/JJfb+4 ncDT5l7QExD82rgM556iGPg0n+YSaA3ChZz2SbYZ9Z1jSNVZDsU= =kuPx -----END PGP SIGNATURE----- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
