[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Replacing ldconfig maintscripts with declarative methods


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.


[1] Note this applies to the "ordering problem" and not the dependency
resolution problem.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: