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. - 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  Note this applies to the "ordering problem" and not the dependency resolution problem.
Description: OpenPGP digital signature