Hi,
Currently, all Debian libraries (is required to) have a call ldconfig in
postrm and postinst. I would like to replace that with a declarative
method somehow. There are a couple of reasons for this:
* Packages without postinst scripts do not need to be "configured"
explicitly (because dpkg can see there is nothing to do for them).
This provides two improvements:
- It means there are fewer "constrains" for dpkg and APT to solve
to compute an ordering for install/upgrades[1].
- dpkg can also safely break dependency cycles at packages without
postinst scripts, since it knows that the package will not need
anything from its dependencies to be configured.
=> I know that there are people trying to remove dependency cycles
all together. This solution does /not/ intend replace that
goal. It will only improve the chance that dpkg can safely
handle a given cycle.
* There are also some "minor" optimisations like:
- We can remove thousands of postrm+postinst scripts.
- We can remove the "hack" in libc-bin to replace ldconfig calls with
a no-await trigger (see below)
The current state:
* Packages have the scripts to call ldconfig
* To reduce install time, libc-bin replaced /sbin/ldconfig with a shell
script. This detects whether it should immediately call (the real)
ldconfig OR (if called from a maintscript) should call dpkg-trigger.
- ldconfig calls dpkg-trigger with --no-await, so it will not cause
trigger cycles.
A possible solution is to replace these scripts with an
"activate-no-await" trigger (again, no-await to avoid trigger cycles).
I would need libc-bin to promote its trigger to part of its API for this
to work. Also, I need some help understanding some corner cases:
* 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)
* Performance-wise we would see up to 5 calls to ldconfig instead of
1-2 per "dpkg run" (that processes triggers).
- Being no-await, dpkg have freedom to "re-order" and "merge" all
the activations.
- In the long run, it might make sense to get support for only
activating triggers at certain "states". Though I doubt the
performance overhead will be the greatest issue
Feedback is very welcome. If this idea is uncontroversial, I move
forward to update debhelper+lintian as well as file bugs against policy.
Thanks,
~Niels
[1] Note this applies to the "ordering problem" and not the dependency
resolution problem.
Attachment:
signature.asc
Description: OpenPGP digital signature