Dpkg Postponing Tasks Mechanism (DPTM)

Something very similar has been implemented as DpkgTriggers.

See the spec: http://lists.debian.org/debian-dpkg/2007/04/msg00076.html

Rationale

During Debian package installation there exist several tasks that are executed by many packages repeatedly because:

For this reason we are going to develop a mechanism for integration with dpkg designed to minimize the number of redundant program calls, especially WRT IO/CPU time consuming applications like ldconfig.

Integration Policy

There are two types of applications covered by the postpone mechanism. Those that have dependents (ie. packages that rely on a certain state of installation which is not reached if a postponed operation is not executed yet, eg. modprobe on "depmod -a" calls) and those that don't (eg. menu-update).

Case1: strong dependency

When other packages require a certain state and therefore depend on a feature/state providing package, the postinst scripts of the client packages need to make sure that relevant outstanding operations are executed before the dependent operations can begin.

Decission to make use of DPTM to reach a certain goal must be met by consens between all involved stakeholders: maintainers of state providing package as well as their "customers", maintainers of packages relying on them. The issue should be brought up on a medium where most involved partys are listening/reading (eg. pkg-FOO-group-devel mailingl list on alioth) or via private email communication.

When a consens is reached, the preparation phase begins. Client package maintainers need to begin to integrate the execution triggering command (see Usage policy) into their postinst script, if required. (FIXME: changes to integrate DPTM can be declared as BSP goals justifying 0-day severity).

When all or a sufficient majority of client packages is adapted, the postponing hooks can be installed into the feature providing packages. Note that those packages need to conflict with all versions of client packages which may become broken because of that change (eg. foo (<= adapted_version) for all client packages). In the case of a large number of such client packages, the begin of this phase can be coupled with a Debian release (at which point all client packages must be converted).

Case2: no dependency

Without strong dependencies, the packages can run the hook client (ie. install postponed tasks) as done with usual program calls. To speedup the transition, DPTM package can install wrappers that emulate the behaviour of programs (eg. ldconfig) while postponing them.

Usage Policy

The provisoric name for the DPTM client command is "dpkg-hook". Basic usage:

Implementation Ideas

DTPM has main these tasks:

The post-execution process should display status message like: Executing pending tasks:

And dpkg.log would contain things like:

2006-03-14 08:04:15 status post-configured libfoo 2.6.15-8 fooconfig (+option: "/lib/a /lib/b")

2006-03-14 08:04:15 status post-configured libbar 2.6.15-8 fooconfig (+option: "/lib/bar")

2006-03-14 08:04:15 status post-configured libbaz 2.6.15-8 fooconfig (+option: "/lib/baz")