On 2015-08-29 23:52, Aurelien Jarno wrote: >[...] > >> * The major concern I have, is that "activate"-triggers are done for >> - unpack (is this ok?) >> - configure (ok) >> - remove (ok, assuming it is post-removal) >> - purge (should not be an issue) >> - deconfigure (would be a no-op, since the library is not actually >> removed at this point) > > As a general rule it should not be a problem to call ldconfig at any > moment. Therefore I don't see a problem to call ldconfig in the above > steps. > Excellent! :) > What we should ensure is that if package A depends on package B, > ldconfig is called *before* starting the postinst of package A to fill > the cache with info from package B. Ok. I was not aware that we had this requirement. However, the current setup does not enforce it AFAICT. It seems that triggers are the very last thing to happen! """ $ aptitude -R install mscgen [...] Unpacking libgd3:amd64 (2.1.1-4) ... Selecting previously unselected package mscgen. Preparing to unpack .../mscgen_0.20-4_amd64.deb ... Unpacking mscgen (0.20-4) ... Setting up libexpat1:amd64 (2.1.0-7) ... [...] Setting up mscgen (0.20-4) ... Processing triggers for libc-bin (2.19-19) ... $ """ However, if we move to explicit triggers, then dpkg will now trigger ldconfig just before running postinst scripts: """ $ apt-get install ../mscgen_0.20-4+ddebtest1+triggers1_amd64.deb [...] Selecting previously unselected package mscgen. Preparing to unpack .../mscgen_0.20-4+ddebtest1+triggers1_amd64.deb ... Unpacking mscgen (0.20-4+ddebtest1+triggers1) ... *Processing triggers for libc-bin (2.19-19) ...* Setting up libexpat1:amd64 (2.1.0-7) ... [...] Setting up mscgen (0.20-4+ddebtest1+triggers1) ... Processing triggers for libc-bin (2.19-19) ... """ As long as one package have the explicit trigger, dpkg it will now trigger it correctly. In my particular test case, I added it to mscgen (despite it not being a library). >> [...] > > On the performance side, ldconfig has a cache mechanism, which makes > calls to ldconfig very very cheap if nothing has changed. So I don't > think it would be a problem. > Excellent. :) >> Feedback is very welcome. If this idea is uncontroversial, I move >> forward to update debhelper+lintian as well as file bugs against policy. > > We currently have ugly hacks removing ldconfig.real in case it will break > the system in the preinst script. If we go for this solution, we should > not forget to change that part also. > > Aurelien > Ok, currently this is guarded by a: if dpkg --compare-versions "$libc_bin_version" lt "2.18-2"; then AFAICT, what will happen is: * libc6 preinst upgrade will disable ldconfig * dpkg will unpack stuff incl. libc-bin - This will restore ldconfig * dpkg will run the trigger (unpack) - This will run ldconfig * dpkg will configure stuff as usual This seems to be similar to the old approach, except the trigger will now be run before configuring packages. Thanks, ~Niels
Attachment:
signature.asc
Description: OpenPGP digital signature