I'm not happy with the design of ComplexEventConfig, so I want to try and capture the use cases we're actually trying to solve, and how they should behave. Then we can work out what we actually want.

Task to mount a disk is run on the fstab-device-added event, and needs the information from that event to know which device to mount. However it's possible that it's not possible to mount that device yet, because a path above it in the tree isn't mounted yet. It should be possible for the task to fail, and be run again on subsequent path-mounted events. Optionally we might want the information from the second event as well to decide whether to bother trying (e.g. /var mounted when waiting for /usr, little point waiting).

fstab-device-event information needed until task is complete.

Probably want to block the event too, since this is the task that handles it.

Don't want to fail it immediately, since we can try again later.

Optionally include filesystem-mounted event information, you'd certainly want to know that it was that event.

If we block that event, we only want to block it until we have the job running since we might not care about this event.

Various web-related services will only need to be running when both the web server and database server are running. These services need to be stopped before either server can be stopped.

Both stopping events should block.

Many services require both networking and a filesystem. Networking might be defined as the period between a network-up and a network-down event. Filesystem might be a job that should be running, or might be defined as the period between two events.

Periods between events ("states") need to be first-class.

Jobs should also define these states, either as the period between its started and stopping events or just directly referencing the job state. (If filesystem is a job, it can't be its goal).

Combinations of events and states need to be legal (X needs to be started with a filesystem when certain tasks are complete).

lrm-manager needs to be run before we can start udevtrigger or read /etc/modules.

If this is done from those jobs, then there needs to be a way to mark something optional only if a job exists; since lrm-manager is not required.

Alternatively lrm-manager should be able to be started by either, blocking the starting event; but only run once.

Some services need to be restarted when something changes in the system (represented by an event). it should be possible to specify it.