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